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PART I — Introduc t ion 


chapter t what is XXDP<^ 


*XDP* is the dia^cst ic operating system for cxlp/l st-T 1 ‘s. The 
purpose of this manual is to describe the operation of the XX£>p« 
System, It has been written for use by both new and experienced 
users. Chaotrr 2. contains advice on how to use this manual. TV 
glossary (Appendix G) has definitions of terms used in this 
manual . 

the XXDP* System consists of four major components. These are 
the monitor, the diagnostic runtime services, utility programs 

and loadable dev drivers for the utilities. The tour 

opponents work together to accomplish the system fuhe t loraiity. 

The MONITOR component is the highest level software and forts the 
core of the system. At ! of the other components require monitor 
support for their operation, the monitor provides program load 
and execution, console terminal services, batch control and file 
services (loading and reading files) tor the system medium only. 
The system median is the storage medio* on the device from which 

’he monitor was loaded. All other components utilfie the 

terminal services for operator communicat ions and -he file 
services for certain operations described later. 

The RUNTJMf SERVICES are an extension of the monitor which 
provide non-diagnost ic function support for certain tvoe* of 
diagnostic programs. These diagnostics are commonly referred to 
as ^supervisor compatible”. Among the functions that the runtime 
services provide are a standard operator interface, error message 
formatting and control of diagnostic operation. 

The uTR’fy PROGRAMS *a re used for file manipulation (e.qu , moving 
files fr m one place to another), diagnostic pre-parameter it at ion 
(creating diagnostic files with hardware information attached)* 
ile modification (’batching”) and creation of batch control 
files. The ut i l ity programs use the monitor for typing and 
receiving messages and for loading the -eed/wr ite device drivers 
required for file operations. 

’he fourth component of the XXDP* System is the collect ipp of 
device handlers, or DRIVERS. These are used by t >e various 
utility programs to access storage media and I/O devices. They , 
-ue resident on system sto-age medium and loaded into memory as 
'eqt.ired. (The system storage medium is the medio* from which 
x *»>*’♦ was loaded.) 

•he name ”KXDP*“ was derived m the following manner* the 
characters "%%" represent the two character codes' u-erd to specify 




Page S 



G 1 

*»0'* S i s t em i , s e r *% M*nua l 

Irt r OduC f Or 


The media supported by any partuulir monitor. * o r example, 
D*DP* is tne XX DP* System fo r the RXO 1 . which 's ’dent i f ied by 
the mnemonic ’T>x’\ The characters 'T>P” stand for 'Diagnostic 
rac> age", referring to the primary function of the system.- 
diagnostic release and distribution. The ”♦'* di f ferent iates this 
system from XXDP, the forerunner of XXD°+. 

When ordering or discussing the various software components o* 
XXDP*. vou should always refer to the component name. A 
component n«we would be ‘TWAO XXDR* DX MONITOR BIN** for 
e»amote . *he first seven characters of the name have special 
significance ar*J in most cases the name of the file for a 
specif c software component is derived from these characters. To 
explain the s i gn i f i c anc e , let’s break the word into four groups 
of letters: ‘TM-M-DX-AO’’. The first group of two letters 

signify the tXDP* family of software and docunentat ion. Only 
xx5p* ^elated software have names beginning with 'Th‘\ The ne*t 
charac te ‘ defines what type of product the component is. ’V 
means that this product is a monitor. Other codes represent 
utility programs (U> , device drivers (D> , runtime services' f S > 
and manuals (0) . The third group refers to either the device 
supported (in the case of monitors and device drivers) or type of 
software (in the case of utility programs or runtime services'. 
Append i» M has a list of the device and Software type codes. The 
last letters refer to the revision and oaten level of the 
component, AO is the first version of the component , 01 would 

be the first revision with one patch, or temporary modification. 

Examples 

CmWDKBO — B revision of R*0$ Monitor 

CHUSUAJ — A revision of SE TyP utility with three patches 

CMDOXAO — A revision of RxQT driver 

f or a complete list of components (without revision levels), 
please refer to Appendix M. 

The f i 1 e names for all components other than utilities are t*<;ed 
on these names. To derive the file name from the component name, 
drop the X** and take the next six characters as the file name. 
All components, except utility programs, have *’.W’ extensions. 
The utility programs are distributed under their common names, 
t ike tAW and xTfCO, for user convenience and have ".BIN" (or 
".BIO extensions* 
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raoter ? mo** to Use tWj manual 


This nanuai is divided into eight sections. Inc l uding tnfs 
introduc tory section. In addition to toese chapters on XXDP* and 
the manual , tne introductory section (Part T) also contains the 
terminal if. ter face and file conventions (Chapter 5) , Alt users 
should famil iar iyet themsel ves with this informat ioo. The ne*t 
four sections describe the major components of xxDP* in detail, 
the next section (Part Vl> describes how to build XXDP* on a new 
piece of media using any other XXOP* media. Part' Vi I describes 
the batch control features of XXDP*. The final sect on contains 
appendices with information valuable for all XXDP» users. There 
is also an index for quick reference use. users should 
fami l iar i/e themselves with this section of the manual. 

If is reco m mended that the new user carefully read each section 
u. order. Waster one section before attempting the nett. Each 
section has several examples of actual usage that will aid the 
reader. XXDP* is not an overly complicated system* but a new 

user can have problems if he or she does not carefully read this 
doc uwent . 

The experienced user should real over the various sections to 
review his knowledge of XXDP* . This manual contains information 

not published in previous maruals. The presentation of the 
material has been improved for better user understanding. The 
index will be of particular value to experienced users sin^e it 
enables one to guickly find references to selected items. 

There are two conventions used in present inq command formats 
throughout this manual . first, a field, or item, in a command 
that is a variable (such as file names) is denoted by the use of 
lower case characters. f elds shown in upper case character? 
must be entered exactly as shown. Second, optional fields In a 
command are enclosed in square brackets. Sample format 
statement : 

R f ilnam [addrl 

In Th*s case the operator must type followed by a Hie name 
(I ike UPf>?>. The operator may also enter a starting address, but 
it is rv>f required so the field is marked as optional. 

nne final note. This manual was prepared by and is maintained by 
Diagnostic Systems Engineering. Comments and suggestions are 

welcome. Internal users (Off employees) should refer to the PEC 
phone directory listing for Diagnostic f nginee r inq 1 Wanly 
sterns. f xfrrnal users should contact their sates 
represent#? i ve. 
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Convent ions 


there ere two conventions that i user must be aware of when 
work ing *nth vxr>P*. They are the terminal interface ard file 
conventions, this chaffer describes these two convent ions. 

T#»rfMnai Interface 

The console terminal is supported as oar? 0 f the *XDP* monitor. 
The console terminal driver is a simple, flag-driven handler. 
If lag-driven means that no interrupts are used. >»ns is done to 
pre.e* t unsolicited interrupt from interfering with £■' ;g.»ost>t 
programs. > The driver m*k#s no <M*~* inct ion be tween upper and 
lower case characters. All printing characters are supported, 
but some characters have special significance in specific 
situations. The table below lists these special characters. 
This table briefly describes the ♦unction of the characters. 
Detai ted descriptions and examples are left f e later sections of 
♦his manual . 


Char 


delimit a device spec f f it at ion (e.g. , Cx.C? > 
start comment line in a batch control fit# 
beginning of a three character extension in 


beginning of a three character extension in a file 
name (refer to nest section of this chapter > 

? ’Vi Id' ard” character (refer to newt section of this 
c hapter ) 

* ’Vildcard'* spec i t f? at ion (refer to nest section of 
this chapter) 

*■ separator between input and outout spec if ic at ions in 
a command 

< equivalent to *v* 

/ command switch 

Jn addition there are four control characters supported by the 
terminal driver. These are listed in the table beiow. Control 
(haracte r s depicted with an tp-arrow are typed by depressing the 
‘ t TRl key and then typing the designated letter at the same 
t ime. 


Char 


Stop current activity ang return control to 
delete entire line of input so new line can 
inhibit typing IkQf f ) 
resume typing ( *0h> 


gram 

fvoed 


i 
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file Convent ions 


XXDP* fues are specified by a name and extension. The name may 
be up to six characters in length and the extension may be up to 
three characters in length. The name and extension are separated 
by a dot (.). Only alphanumeric characters <A~7 0-9) may be used 
and spaces may not be imbedded. Sample fiie names: 


; UTD2.BIN 

I HSAAAO.SYS 

TEST . 1 
XMONC0.L IB 

The user would find it very inconvenient to have to type every 
file name in an operation involving many files or to have to get 
i a list of every file on a medium just to get a directory of a 

; certain type of files. To avoid this problem. XXDP* allows the 

! use of ’Wildcard characters". These characters. *T* and can 

be used as a substitute for a character or a string of 

characters, respectively, in a file specification. The easiest 
| way to explain the function of wildcards is to illustrate their 

i use with an example. 

t 

‘ If a user wanted tc obtain a list of all files on a medium that 

; have ".CCC" extensions, he or she could get a directory of the 

! entire mediim and took for files with that extension. Or with 

the use of wildcards, the user could ask for a directory c 

* .CCC". This would tell the file se. vices to look for any files 
with *\CCC" extensions and any valid string of characters for a 

name. Other examples of the wildcard characters are: 

XW0N??.LI8 ill files whose name starts with 
the character* "XMON" and ends 
with any two otner valid 
characters (or nulls) and have 
the extension *1 IB" 


XM0N*.L18 same effect as above 

XMONC0.* all files with the name ' 'XWONC O’ 

and any extension 


XM0NC0.??? 


same effect as above 


One further observation regarding file extensions. Some 
extensions are used to identify particular Tile types. For 
example, batch control files have ’.CCC" extern inns. Below is a 
table of extensions that have particular meanings. 
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BIN 


SIC 


SYS 

CCC 

OBJ 

LIB 

TXT 

BAK 


a i executable program f 
not be run or loaded in 
operat ion 

• an executable program f 

, be run or loaded in 

operat ion 
a system file 
a batch control tile 
a DEC 'Xll object module 
a library file 
a text file 
an vTECO backup file 


ite that may 
batch control 

ile that may 
batch control 
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PART II — XXDP* Hon i tor 


Chapter 4 Brief Description of Hen i tor 


The purpose of this chapter is tc give the user a general idea of 
how the XXDP* monitor is constructed. I f a user knows something 
ibout monitor construction, it may enable him or her to better 
understand monitor operation. Also, since XXDP* is typically 
u >ed in field repair situations, knowledge of what the monitor is 
and does may assist the technician in identifying and resolving a 
problem. 

At load time the XXDP* monitor is about 4K words in size and 
consists of three major sections: secondary- bootstrap, 
initialization code and the '■untime monitor code. The secooda-y 
bootstrap is loaded into memory at boot time and loads the 
remainder of the monitor into memory. Chapter 5 explains the 
load process in more detail. The init ial izat ion code gathers 
certain system information and relocates the runtime monitor. 
The runtime monitor is the code that is used to carry out the 
various operator functions described in Chapter 6. The start up 
process is described in more detail in the next chapter. 

The runtime monitor consists of five sections; read-only device 
driver, console terminal driver, monitor services handler . 
operator interface handler and batch control handler. The 
read-only device driver is used fAr loading programs from the 
system medium and reading batch control files. The operator 
interface handler processes operator commands from the console 
terminal. The batch control handler processes batch files from 
the system medium. The services handler processes requests for 
monitor services which are made by utility programs via the EHT 
instruction. The runtime monitor is approximately ,?* words in 
size. Since older diagnostic programs expect the size to be 
1 .Sk, however, the monitor's lower ,5 k may be overwritten by a 
diagnostic program and then later restored by the monitor. 
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Chapter 5 Starting the Monitor 


This chapter is divided into two sections, first, the procedure 
tor starting the XXDP* System is described. And second, tne 
process that occurs when the system is starting is described. It 
is assuned that the reader is familiar with the peripheral device 
being used as the system device. 

XX0P* System Start-up Prpcedu .* 


Step T 

Malt the processor (af t^r making sure that any operating 
software has been “graceful l y shut down). Mount/load your 
XX0P* mediu*. If you are working on a system that has unknown 
hardware problems, make sure the load device is write 
disabled. 

Step 2 

Re-enable and boot the processor. for your convenience, a 
nctnber of boot procedures are listed in Append i* 8. 

Step 3 

When the monitor has successfully loaded, it will identify 
itself, memory sure (14) to 28* words) and the drive rxjuber 
from which it was booted (multidrive devices only' . An 
example *'s: 

CMMDK80 XXDP* OK MONITOR 
800TCD VIA Uf IT 0 
2 4K UNI BUS SiSTfM 

This is the message that would be printed after booting cn 

RK05 monitor on a system with ?4K words of memory, using dr.ve 

0. The monitor will then relocate the runtime monitor code to 
the top of available mc-tor y tup to 28* wor^s) and transfer 
control to this code. 

Step 4 

The monitor will then ask you for the Jate. Type the date in 

standard format; i.e. DD-MWM yy (pay - month - year). If 

/ou wish, you may simply type a carriage return. In this case 
the date will be set to 01-JAN-70. After the date has been 

accepted, the monitor will print an address that may be used 

to restart the monitor in the event that the processor must be 
halted and restarted. 

when these steps have been successfully completed, the monitor 
will type a dot ( . > to prompt the user for commands. The user 

may new use any of tne commands described in Chapter 6. 



S/Mem use r 
Monitor 


N 1 


XXDP* Start-up Process 


T he pua * ; 4 > section of rhe chapter is to give the user 

some M"'.! "-'f • he process that occurs when he or she starts the 

monitc~. ; m , this is to assist the user in understanding and 

* g * he «w< 1 tor . 

fyV you ii.il' the t cad device, the first physical b*ock of data 
the medium ’S loaded in»o the first 256(10) words of memory. 

. data is the secondary bootstrap. Control is passed to it 
? um the hardware, or pnmarv, bootstrap. The secondary 
bootstrap reads f he emainder of the monitor from the load medium 
into memory. The load begins at memory location 1000(8^ and ends 
at ?QW0(8) (the * X boundary When the load is i omplete, the 
secondary bootstrap passes control to the initialisation code and 
the boot process is complete. If a detectable error occurs 


during 

halt. 


secondary 


tstrap operation, the prc.^essor *iU 


Appendix A describes these halts in detail 


It the boot process is successful, the monitor will s i /e memory 
(up to 28*. words), si/e for the presence of standard line or 
proqra mm abl e nocks (XW-11L and KW-1 IP) and si /e for bus type. 
If the bus type cannot be determined, the monitor will ask f he 
user to specify the type (IJNJBUS or Q8US>. The monitor will 
identify itself, print the unit nunber from wh.th it was booted 
ard prmt the system si/e and bus type. It will then «$k for the 
due in DCC standard format: day-month-year (i.e. , 25-0 €C-8Q>* 

The user may simply type a return and the date wilt default to 
1 - ,iA»WQ. Next the monitor will print its restart address and. 
finally, relocate to the top of the memory (up to 28 K words). 

The XXDP* monitor is designed to assume that you wilt ooerating 
with US-type (60 cycle' power. if you will b<* using 
Furopeir -type r 50 cycle) power, you must modify the monitor, 
location 1000 .ontains an indicator or power type. 0 for 60 cycle 
and 1 for 50 cycle. Chapter 11 cm UPD2 explains how to modify 
tiles, but a brief example is given here. 

s ip o? 

1 *«HD. . !>vS 

?M 100c . 

iftfhoo oooooo 1 

4 i/W P? v * 


Tr.*= underlined portion in the above example is 
*», r-er his modif ed the 8X02 moo, for and s 
8 ifmj *p in drive 0, rep lac ing the monitor 


floppy 
On the 
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; ' J er 6 Monitor Commands 


, chapter describes the monitor commands available to the 
. *> e r . These conmands are summarized in Appendix C tor the 
experienced user The following commands are detailed in this 
chapter : 


R 

! 


h 

TES! 


run a program, 

load a program 

start a program 

run a batch job (chain) 

list directory of load medium 

set the terminal fill count 

enable alternative drive for 

system device 

type help information 

run a batch file called 

SYSTEM. CCC 


Some c >mmands have optional ’’switches" which consist of a single 
character proceeded by a These are used to modify the 
command function. 


fun Command 


The run command s used to load and start a program? 
stored on th>* oad. or system, medium. (Note: th« 

is a combinatk of the load and Start commands dest' ■ 

The program must be an executable fil<*. These ar*- 
witM .BIN or .SIC extensions to their names (such as. 

The format of the run command is: 

R fi InanC c x 1 3 Caddrl 

The file name must be a standard XXDP* file name (see Chapter 3). 
The default extension is .BIN or .BIC. If ‘here is a f<»e with 
both extensions on the medium, the first file found will be ured. 
After the program is found and loaded. but before the program is 
started, the full file name will bel printed to verify the load. 
This is useful in determining which of possibly several programs 
on a mediun is being run after a wildcard specif ication. The 
file will be started at the transfer address in the file (or at 
200 octal in the absence of e transfer address). The operator 
may optionally specify a starting address. Some examples of the 
run command: 

R UPD? (load/s tart UPD2.8J?) 

R SAMPLE. XXX (load/start SAMPLE. XXX) 

R RXDIAG 204 (load/start RXDIAG.BI ? at location 204) 


Page 


Wildcard characters are permitted in the file spec i f ication. The 
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I first file found that tits the wildcard description *Ul be run* 


Load Command 


The 'oad command is used to load a file 'ntc memory. This 
command r.ay be thought of as the first half of a run command. 
The program is not started. As in the run command process, the 
full file name of the program that was loaded is printed. All 
restrictions in the run command apply, 'he format of the load 
command is: 

L filnamC.extj 

Some examples of the load command: 

L 01 AG (load DIAG.8I?) 

L ZDJCA2.NfcW (load ZDJCA ( ?.NfW) 


Start Command 


The start command is used to start 3 file that has been 
previously loaded into '■ore by a load command. No commands 
should be issued between a load and start command since the 
program loaded will most likely be overwritten. The purpose of 
this command sequence is to allow the user to load a program, 
halt the processor, modify memory contents, restart the monitor 
and start the program. The format of the start command is: 

S Caddrd 

The user may optionally enter a starting address. The monitor 
wilt start the program at the transfer address in the file if the 
operator does not enter a starting address. The default starting 
address for files without specific transfer addresses is 200 
(octal). Some examples of the start command: 

L RXDIAG (load RXDIAG. 81?) 

S (start at transfer address) 

t RXDIAG (load RXDIAG. 81?) 

S 204 (start at 204) 


Chain Command 

The chain command is used to initiate execution of a batch, or 
chain, file. The file must be on the system medium and must have 
a . CCC extension. Some batch operations accept switches. This 
will be detailed 3 documentation tor the batch file. The format 
of the chain cornu nd is: 


C f i InamC/swi tchesj 
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Part VII of this manual describes batch control in detail. 


Directory Command 


The directory command is used to obtain a list of all the files 
on the system medium. This list will contain five items of 
information: the entry number, the complete file specification 
(name and extension), the date the file was created, the length 
of the file in 25b (decimal) word blocks and the nunber of the 
first block in the file. Most files are ’’linked"; that is. 
their blocks are not in order on the medium. A few files are 
contiguous; that is, their blocks are in order on the mediun. 
Contiguous files are noted in the directory by a *t" following 
the date. 

When the directory command is given, the monitor must load the 
directory utility (HUDI ??. SYS) which in turns requires the 
read/write device driver for the system medium type. These two 
files must be on the system medium in order for the directory 
command to work. I f one of these f i les is not on the medium, the 
monitor will type an error message. The format of the directory 
command vs: 

DC/UC/ri 

There are two optional switches for the directory command . The 
"/I" switch will cause the directory to be printed on a line 
printer rather than the console terminal. The /F" switch causes 
the directory to printed in a short form. This short form only 
gives the entry number and file name. Ex nples of both forms are 
shown below. 


Directory Long form 


ENTRY# F J l NAM .EXT DAT* 

1 HMDKAl.SYS 02-JUN-79 

^ HOOK AO. SYS 02-JUN-79 

3 HUDI AO. SYS 0?- AUG- 79 


LENGTH start 

12 000100 

5 000100 

6 000066 


DIRECTORY SHORT FORM 


1 HMDkAl.SYS 

2 HDDk A0. SYS 
5 MUD1A0.SYS 


Fill Command 

The fill count is used to control the 


nunber of fill 
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(non-print ing) characters that will be typed after a carriage 
return. The fill, or null, characters are typed to allow time 
for the carriage return before typing the next line, thus 
preventing overprint ing. The terminals that require a fill count 
are: ASR, IA50. VT05 and VT50. The format of the command is: 


f 


e monitor will print the current fill count and t‘ien wait for 
the user to type the new fill count. If the user does not want 
to change the count, he or she should not type a number, but 
simply carriage return. Some examples of the fill command: 

f 

000005 (fill count = 5) 

f 

000010 1 (new count = 1> 

The fill count is initially set to 14 in order to allow the 
monitor to start properly on a system that has one of the 
terminals that require a fill count. After start-up. the fill 
( ount is always reset to 0 since most terminals do not require 
fill counts. The user can immediately reset the fill count if 
desired. 


5f0 001 


f nab l e Command 


The enable command is used to change the drive that the monitor 
* considers to be the system device, for example, if the user had 
booted the system from drive 0 of an Rk 05 and later wanted to 
have the monitor use drive 1 as the system device ( that is, as 
the default device), he or she could do this without re-booting 
the monitor by using the enable command. This command is valid 
for multi-drive devices only and affects drives, not controllers. 
T> fo-mat of the command is: 


£ n 

.where n is the new drive number. 


Help Command 

The help command is used to obtain a brief summary of x*^R* 
commands. The contents of a file named IR. TXT” are 
typed/pr inted and this file must he on the system medium. there 
is a switch to cause the summary to be printed on a line printer 
instead of the console terminal. The format of the command 's: 


Hi A 3 
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Monitor Error Messages 


T he monitor can detect the following problems and will report to 
the console terminal as shown. Note that all error messages 
begin with a Question njrk ("?"). 

Inyal id Command 

? invalid command 

the user has entered a command that is not recognisable to the 
monitor. Check yOur command line and retype. Monitor commands 
are discussed in Chapter 6 and are svmmarf/ed in Apoendi * C. 

Inyal id M lename 


? INVALID f Ilf NAME 

The user specified a i. lename in the previous command 
not in the proper format. 

Bad Address 


was 


? BAD ADD* 

An invat id address was specified with a run or start command, 


Checkstm Error 


ChERR 


The monitor’s driver c he* k sums a file as it is loaded. If the 
computed checksum fails to match that stored with the file, the 
monitor reports a checksum error. You may retry the load, but if 
the error persists, the f>le image has probably been corrupted. 


lookup Error 


The spec i f ied file war 
possibil it ies: 1 ) you 

is not on the system r » 
read filer that art 
(cwmsnd to get the cor - 


Read Error 


? N0 r ► OUNO : fllnam 

nor found by the monitor. There are two 
'pel led th? file name wrong or 2* the file 
d '■ r- . (Remember, the monitor can only 
on tie system medujm'i use the directory 
ect spell ing. 


? RD ERR 


A dev U e error occurred while reading from the system device. 
Rrrtf the operat ion. If the error persists, SuSbect that the 
hardware may have a hard error or that the med um is bad. 
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PART Hi — Diagnost i c Runt ime Services 


Chapter 8 Desf r pt ion of DRS 


The Diagnostic Runtime Services (DRS> are the part of the XXDP* 
System that control compatible diagnostic programs. This program 
is an extension to the the XXDP* Runtime Monitor that* is 
automat ical ly loaded into memory and started when a compatible 
diagnostic is run. DRS also provides non- test -related services, 
such as console terminal support, to these diagnostic programs. 
Al I diagnostic programs that are compatible with DRS share some 
’ moor t ant common features. Because of these features, they have 
identical structures, respond to the same general set of 
< omm«*nds. -eport errors in the same way, gather hardware and 
operational data in the same manner and are therefore easier to 
use and control from both a user and system point of view. 

If you are insure of wh'Ch diagnostic programs on a particular 
medium * e DRS-compat itsle, you can use the $f TuP utility to list 
these diagnostics. Chapter H de tribes Si UJP. 

DRS Start-up 

The start-14? procedure for DRS is relatively straightforward. 
The user issues an XXDP* run command and the diagnostic is loaded 
and started. The first thing the diagnostic does is to execute 
an CRT instruction which transfers control bach to the XXDP* 
monitor. XXDP* then loads DRS from the system medium. The DRS 
file is ‘MSA, ??". where "??" represents the revision and patch 
level . DRS sizes memory using memory management prior to going 
into command mode. I f this hardware has problems. DRS will not 
start properly, you must run memory management diagnostics if 
you encounter this problem. 

DRS Concepts 

The user should be aware of several %,onceots about DRS. 

COM SOU COWHANDS - DRS uses the console terminal for 
communicat ing with the user. There are eleven commands 
available to the user for control l ing DRS operation. (These 
commands are explained in the next chapter.) unlike older-type 
diagnostics, DRS does not vary its operation based upon 
starting address or "switch registers". 

COWHAND WOOIHfRS (SWITCHCS) AND f i AGS - The user may alter 
the effects of a particular command by specifying a switch" 
when the command is given. for example, unless otherwise 
specified, most commands will affect all units (devices) that 
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T*e dia/iost ic can rest. A switch can be used to ii«nt the 
effect of c ommanos to certain cnits only. 

UNITS - The diagnostic acts i 4 xx> specified hardware* Each 
individual hardware "entity" is referred to as a 
un -ur der-test (UUT) or, most commonly, as a unit. DAS is 
r quipped to handle up to 64 units, the user refers to a unit 
by a ryariber , The first unit is ’ t>". Units a r e nattered 
according to the order in which they were specified l see 
HARDWARE TABLES below). 

HARDWARE PAR AME TER TABLES - DRS-compafible d i acre’s tics do not 
autos i/e (determine hardware 1 nto'mat ion by oertorming 
bus-related tests). The user must give the diagnostic the 
information about the hardware under Test that is necessary, 
this information is stored in a set of tables called "hardware 
parameter tables". Tnere is one taM * for each unit to oe 
Tested. The specific information required is dependent upon 
the diagnostic. There art some general rules that are 
explained in section 4 of Chapter 9. The diagnostic program 
will prompt the operator for the information it needs for each 
unit, starting with unit 0. The important concept that the 
user must grasp is the concept of a "table driven diagnostic" 
in all of the information about a hardware 'unit »s contained 
in a table specific to that unit. 

SOFTWARE ARAMETER TABLE - There are operational parameters 
that the user can select that affect the way in which a 
particular diagnostic will function. This information is 
placed into a table of data called the "software parameter 
table". r h is table ( for those readers familiar with earlier 
processor designs) takes the place of the switch register. 

PASS - A pass, or unit of diagnostic operation, is defined to 
be the execution of all specified tests tor all active 
uni ts-mder-test . 

TEST - DRS diagnostics are divided into independent stuc tunes 
called rests. The user may run all tests in a diagnostic or 
select any subset desired. 

Error Messages - when a diagnostic detects an error in the 
device being tested, it calls upon DRS to report the error to 
the operator. There are three levels of error messages: 
header, basic and extended. The first message level supplies 
some general information about the error, as shown in the 
example below: 

/NAME MRD ERR 0000? ON UNIT S f ST 01? SU3 000 PO01 St $4 
The information given in the header is; 

diagnostic name - "/NAME" 

error t r>e - 'TiRD" 


Page ?0 




W! 



XXDP* System User’s Manual 
DiagnoSt k Runtime Services 


Sfi t \V 


i 2 

Page 21 


error ntUlber - * XK)Oo2’ ' 
unit number - "5“ 
test nunb «r * *12*’ 
subtest number - *0" 

locat ion of error call to DRS - ”013154" 

The error number is for identification and is not a running 
total of the number of errors that have occurred. 

The basic error level is used to give a short , simple 
de-script ion of the error. The extended error level is 
typically used to give supporting information such as register 
contents ai the time of the error, for example: 

;um hro err 00002 on uni t 5 tst 012 sub 000 pc .013134 

REGISTER MIUD TO CLEAR AFTER BUS RESET 
CSR: 000000 SCSR: 010000 ERRREG: 000000 

The first line is the header message, the second is the basic 
message and the third line is the extended message. Error 
messages are divided into levels in order to give the operator 
flexibility in determining *»nat portionlsT, if <ny» of the 
error reports will he displayed or printed. I See Chapter 9. 
sect i or. 3. Flags.) 
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Crapter 9 Runtime Services Commands 


THs chapter is divided into four sections. Section 1 describes 
the DRS commands. Section 2 describes the switches, or modifiers 
to the commands. Section 3 describes the operational flags. 
Se< t ion <. describes the table building process that the user must 
to' low. 


Section 1 — Commands 


There »r e eleven commands to the DRS. These commands are entered 
in response to the DRS prompt: DR>. The prompt is issued after 
the DRS is loaded, after all specified diagnostic operations are 
completed, after a DRS detected error, after a oalt~on~error’* 
sequence and after DRS has been interrupted by a *C (CTRi-C). 
These are t. bulated below and described in the remair Jer 0 f this 
section. The commands are grouped by related function. 

Execut ion 


STA »t start the diar ostic and initialize 

RESTART start diagnostic and do not initialize 

CONTINUE continue diagnostic at test that was 

interrupted by a *C 

PROCEED continue from an error halt 

Units Under Test 


DROP deactivate a unit 

ADD activate a unit for testing 

DISPLAY print a list of device information 


F lags 

FLAGS print status of all flags 

/FLAGS reset (clear) all flags 

Stat ist ics 

PRINT print statistical information 


Emitting 

------ 1 

EXIT return to XXDR* runtime monitor 

The descriptions below describe the effect of each command. 
These effects may be modified by the use of switches that are 
described in the next section. Familiarize yourself with the 
commands before trying to use the switches. The commands may be 
recognized by the DRS from a minima* of three characters; thus 
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toe use of the square brackets, that is, the start command can 
be entered as "$TA ,n or ,, $TAR" or "START 1 


Execution Commands 


STACRT.l Command 

The START command tarts the diagnostic from its initial state 
and should be the first command issued to DRS . All 

initial izat ion code is executed. Refer to specific diagnostic 
documentation for exact nature of the ini t lal izat ion process 
carried out by a particular diagnostic. The "trap catcher ’ code 
is reloaded into the vector space. (The trap catcher is code 
that allows DRS to handle any unexpected interrupts and report 
them to the user.) The format of the command is: 

STAfRT]f swi tch-l ist J 

where "switch-list" is any valid comb nat ion of switches 
(modi f iers) for the START command. The switches are explained in 
section 2 of this chapter. The default operation of the START 
command is: all tests will be run on alt units. Alt Maas 

(section 3 of this chapter) will be cleared. The testing will 
continue until into jpted by the user (*C> or b« a system error 
and an end-of-pass message wilt be printed after each pass. (A 
pass is defined tc be all specified emits tested once by all 
specified tests.) 

After you issue the start command, you wilt be asked if you wish 

to hange the hardware information. You must answer yes ("Y") to 

this question if there are ro existing hardware tables. Mradware 
ables will already exist under three conditions. They could 
ha e been entered by a previous start command sequence, by use of 
t e SETUP utility (Chapter 14) or by the programmer who mav have 
hardcoded tables into tne diagnostic image. Already existing 
tables may be overridden by the operator at this point if so 
desired. You will then be asked tor the number of units to be 

tested. Enter the decimal numtoe * of units. You will then be 

asked for hardware-spec i f ic information for each emit according 
to the design of the diagnostic. 

Example of START (underlined portions typed by DRS): 

DR> STA 

CHANGE HU (i> ? V 

0 UNITS (D) ? n 
C answer diagnostic questions] 

CHANGE SW <t) ? N . 

You will be asked for the hardware data tor *Vt" units, where *Yi" 
is a decimal number between I and 64. Refer to section 4 of this 
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chapter for assistance in answering these questions. The 
questions should be obvious and straightforward. If you have 
difficulty with the questions of a specific diagnostic, please 
refer to the document for that diagnostic or direct questions to 
Diagnostic Engineering. 

After you enter all hardware data, you will be asked if you wish 
to change the operational data (software table). This is purely 
optional. You do not have to answer any software data questions 
unless you want to modify default diagnostic operational 
behavior. Section A of this chapter wi » ' assist you in answering 
the questions, but please refer to di , lost u documentation for 
explanations of specific questions. 

If there are no hardware tables, testing will not start. You 
will get an error message. The following example shows what will 
happen . 

DR > S T A 

change mu (l) ? n 

CHANGE SW (L) ? N . 

NO UNITS 

DR> 

As stated above, tables may be created by 1) a dialogue with the 
user. 2> the SETUP utility or, in some cases. 3) by the 
programmer who wrote the diagnostic. 


RE SC TART . 1 Command 


The RESTART command, like the START command. starts t*e 
diagnostic from an initial state. The diagnostic initialisation 
process may be different in response to a restart. Please refer 
to diagnostic documentation for details. The vector space is not 
changed. You will have the opportunity to charge the contents of 
the software table only. The format of the command is. 4 

RESlTART3Cswitch-listI 

where "switch-list is any valid combination of switches 
(modifiers) for the RESTART command. Section 2 of this chapter 
explains switches. The default operation of the RESTART command 
is: all tests will be run on all units, E lags (section 3 of 
this chapter) Are cleared. The testing will continue urn* l 
interrupted by the user (*C) or by a system error and an 
end-of*pass message will be printed after each pass. (A pass is 
defined to all specified <jnits tested once by all specified 
tests. ) 
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Sample restart (underlined port ons typed by DRS): 

DR>RES 

CHANGE SW CL > ? N 


f ONE T I NUt 3 Command 

m* mm* ^ ^ mm «**■ •»* 

The CONTINUE command is used to resume diagnostic operation after 
the user typed controt-C (*C) to interrupt execution or after a 
halt -on-error. The diagnostic will be restarted at the beginning 
of the test that was interrupted, not at the first test, as would 
be the case with the RESTART command. The unit being tested when 
the diagnostic was interrupted will '*emain as tne urrt being 
tested. You wilt be given the opportunity to change the software 
table if vou wish. You will not be able to change the hardware 
tables. The format of the command is: 


C0NtTINU€3tswi tch-l istJ 


where ’’switch-list" is any valid combination of switches 
(modifiers) for the CONTINUE command. Section 2 of this chapter 
describes these switches. The default operation of the CONTINUE 


command is: the testing will run for the number of passes 
remaining in the pass count specified in the last START or 
RESTART command. (A pass is defined to be all specified units 
tested once by all specified tests.) All flags will remain 
set /clear as previously specified. 

Example of CONTINUE (underlined portions typed by , RS> 


sses 

or 


DR > CON 

CHANGE SW (L) ? N 

The user can also use the START and RESTART commands to resume 
diagnostic execution, but diagnostic initialisation will take 
place and testing will start with the first unit, first test. 


P KCEEDJ Coinmand 

The "‘ROlfcED command is used exclusively with the hal t-on-erro*' 
tea* ire in DRS. When halt -on-error is in force and the 
diagnostic reports an error to DRS, DRS return, to command mode. 
The user may issue any commands at thi*. point. The PROCEED 
command is special in that it restarts the diagnostic at the 
point where it reported the error. No initialization is done, 
the unit -under- test is not accessed and the vector space is 
unchanged. This process allows the user to examine the state of 
the unit being tested and then continue testing without 
disturbing diagnostic operation. The format of the command is: 
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where ’ ’swi ich-l ist" is any valid combination or switches 
(modifiers) for the PROCEED command. These switches are 
described in section 2 of this chapter. The default operation of 
the PROCEED command is: the flags (section 3 of this chapter- 
remain set/clear as specified with the previous command. 


Summary of Execution Command Effects 

The following is a short recap of the ef tec cs of each — * jtion 
command. Hfc 

START 

trap catcher reloaded 

diagnostic initialize code executed 

user may change both hardware and software tables 

testine will star with first test on first unit 

all flags cleared 

RE S 'ART 

trap catcher not reloaded 

some diagnostic initialize code may be executed 
use^ may change software table only 
testing will start with first test 
flags are cleared 

CONTINUE 

treo catcher not reloaded 

initialize code not executed 

user may change software table only 

testing will start at beginning of interrupted test 

flags remain in previous state 

PROCEED 

trap catcher not reloaded 

user may not change hardware or software tables 
test wilt be resumed immediately alter error call 
flags remain in previous state 


Units Under Test 


PPOCP3 Command 

The DROP command is used to deactivate a unit from testing. The 
unit to be deactivated must br specified using the unit switch 
(see section 2 ) . All units are initially active and must be 
explicitly deactivated by the user or the diagnostic. The units 
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to be deactivated must already be activated tor testing. The 
format of the command is: 

DROtPH/UNItTShn! 

where ' V," is the number of the unit to be deactivated* The unit 
switch is described in detail in section 2 of this chapter. The 
default operation of the DROP command (when the unit switch is 
not specified) is: all active units wilt he dropped from active 

test ing. 


ADD Command 

The ADD command is used to activate a unit for testing. The unit 
switch is used to specify the unit to be activated (see section 
?). At i units are initially active ano must be ewplkitly 
deactivated by the user or the diagno tic. The units to be 
activated must have already been deactivated. The format of the 
command is: 

ADDt/UNIt TS] :n.l 

where ' Vi" is the unit to be activated. Sec non 2 o* this chapter 
describes the unit switch in detail. The default operation of 
the ADD c om m a nd (when the unit switch is not specified) •** 

deactivated units will be returned to active testing. 


DIStPtAY) Command 

The DISPLAY command is used to ewamine the con* * 
hardware tables. All table data for *he sptf ' 
listed on the console terminV , units that have t* < ■ 
so designated. The format ( * *he c omma nd is: 

OlsrPtAvKswitchH t* 

wh»re "sw i t c h* l i % t ' ‘ is any valid comt 
(modifiers) for the DISPLAY command. f * 
section 2 of this chapter. The default 
command is: all units described in 

displayed on the console terminal . 


f i aqs 


DRS can modify diagnostic opera* n 
several flags that the user fi" 
described in section X of this 
commands related to the use of the-; 
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HAtGSl 

the f LAGS command is used to find the Current Status of the C^S 
ftags. Upon rece*pt of this command, D#S will dispt ay the status 
of all flans on f h# consol# terminal . The format of the command 

>s: 


f IACGS3 

fwamole of * i AGS (underlined portion typed by t^SJr 
D«> LA 

H AGS SET ™ 

NONE 

Mo flags ar# set . 

DR>f L A 

f l AGS SET 

IfR 

LOf 

There are two flags that have been set: If R and l Of * (These 

flags are described in a later section.) 


/HE AGS1 

The /FLAGS command resets all DKS Hags to their cleared state* 
The format of ’‘he command is: 


m TAGS] 
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Sec t ion 2 — Switches 


It is assumed that the reader has read section 1 and is familiar 
with the * [ S commands. 

Switches are modifiers of command functions. For example, many 
DRS commands affect units. Usually a command of this type 
affects all units specified during hardware table build. A 
switch enables the user to limit the effect of the command to 
certain selected units. The DRS switches are: 


/ TESTS : t€St-l ist 
/PASS: ddddd 
/FLAGS: flag-list 
/EOP: ddddd 

/UNI TS:uni t~l ist 


execute only the tests specified 
execute ddddd passes (ddddd * 1 to 65536) 
set specified flags 

report end-of-pass after each ddddd passes 
(ddddd ~1 to 65536) 

command will affect only specified units 


All switches cannot be used with all commands. The following 
table shows which commands each switch may be used with. 


TESTS PASS FLAGS EOP UNITS 


START X X 

RESTART X X 

CONTINUE X 

PROCEED 

DROP 

ADD 

PRINT 

DISPLAY 

FLAGS 

/FLAGS 

EXIT 


XX X 

XX X 

X X 

X 

X 

X 

X 


TESCTS3 

The TESTS switch fs used to specify what tests will be run. The 
default DRS operation is to run all tests, but this switch allows 
the user to override the default. The format of the switch is: 

/TEStTSJ: test-list 

The ’’test-list" is a list of test (‘.umbers separated by colons 
(:'s). If the test numbers are sequential, they may be specified 
by the first and last test number separated by a dasn. For 
example, if tests 1, Z, 3 and 4 are to be specified, they may be 
entered as "1 :<?:3:4" or "1-4". Test numbers may be entered in 
any order, but tests will always be executed in numeric order. 

Some examples of the TESTS switch follow. The underlined porno 
is typed by DRS. 
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DR>$TART/TESTS:5 
DP>STAJRT/TES : 1 : 2 
DR>RES/TES:1 : 5-9: 15 

In the first command, the user has selected test 5 only. In the 
second command, the user has selected tests 1 and 2 . In the 
final command, the user has selected tests 1, 5, 6, 7, 8, 9 and 
1 3 . 


PASCS] 

The PASS switch is used to specify the number of passes that a 
diagnostic will run. A pass is all specified tests on all active 
units. Default DPS operation is *Yio limit” on passes. This 
switch allows the user to place a limit on the number of passes. 
The format of the switch is: 

/PAS CS3 :ddddd 

where "ddddd” is a decimal number between 1 and 65536. Some 
examples of the PASS switch (the underlined portion is typed by 
DRS) : 

DR>ST A/PASS : 1 00 
DR>RE S/PAS: 1 


FLACGS3 

The FLAGS switch is used to set DRS operational flags. These 
flags are described in detail in the next section of this 
chapter. Default DRS operation is all flags cleared. The format 
of this switch is: 


/FLACGS3: flag-list 

where "flag-list” is a list of DRS flags separated by colons 
<:'s). Please refer to section 3 of this chapter for detailed 
descriptions of flags. Some examples of the FLAGS switch 
(underlined portion typed by DRS): 

DR>STA/FLAGS:L0E 

DR>RES/FLA:L0E:IER:80E 


EOP 

the FOP switch is used to specify when end-of-pass messages will 
be printed. These messages indicate the number of passes 
completed and the number of errors found. Default DRS operation 
is to print these messages after every pass. The format of this 

switch is: 
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/E OP: ddddd 

where "ddddd” is a decimal number between 1 and 65536. The 
end-of-pass message will be printed after every "ddddd" passes. 
In the example below, the user is having the message printed 
after every 90 passes. (The underlined portion is typed by DRS.) 

DR>RES/FQP:90 


UNICTS3 


The UNITS switch is used to specify which available units are to 
be tested. Default DRS operation is to encompass al l units in 
the scope of any command. Tnis switch is used to limit the 
effects of a command to certain units. he format of the command 

is : 

/UNJ CT$ I :uni ts-l ist 

where "units-l ist" is a list of unit numbers separated by commas. 
Unit numbers are decimal numbers from 1 to 64. A unit is 
assigned a nunber based upon order of entry into the tables. The 
first unit is unit 1. If the units are sequential , they may be 
specified by the first and last unit number separated by a dash 
(-"). for example, units 3, 4, 5, 6 and 7 may be specified as 
"3-7". Some examples (underlined portions typed by DRS): 

DR>DR0/UNITS:1 
DR>ADD/UNI :2.1 
DR>RE S/UNI : 5-9 

In the first example, the user is asking to drop unit 1. in the 
second example, the user is adding units 2 and 3. And. m the 
last exan*>le, the user is restarting the diagnostic with units 5. 
6. 7, 8 and 9 being tested. 


Combining Switches 


The user may specify as many valid switches, in any order, with a 
command as he or she des i res . Simply string out the switches, 
one after another, on the command line, for example, if the user 
wanted to start a diagnostic a^d: 1) test units 1 through 4 
only, 2) execute tests 1, 5 and 15, 3) execute 100 passes and 4) 
only report the end-of-pass data after every 10 passes, this is 
the command that would be given. 

STA/UNI :1-4/TES:l :5: 15/PAS: 100/EOP: 10 

The table at the beginning of this section shows which switches 
are valid with each command. 


Page 31 


SfO 0031 




XXDP* System User's Manual 
Diagnostic Runtime Services 


G 3 


Sec t i on 3 — ft ags 


It is assigned that the reader has read sections 1 and 2 and is 
familiar with DRS commands and switches. 

flags are used to set up certain operational parameters such as 
looping on error. All flags are cleared at startup and remain 
cleared until explicitly set using the FLAGS switch. Flags are 
also c leared af ter a START or RESTART command ume ss set using 
the FLAG switch. The /FLAGS command may also be used to clear 
all flags. Ho other commands affect the state of the flags. 

E f feet 

halt on e -ror - control is returned to runtime 
se r vices : ommand mode 
loop on error 
inhibit alt e^ror reports 

inhibit all error reports except first level (first 
levef contains error type, number, PC. test and 

unit) 

inhibit extended err^r reports (those called by 
PRINTX mac ro* s > 

direct messages to line printer 
print test number as test executes 
pel t” on error 

unattended mode (no manual intervention) 
inhibit statistical reports (does not apply to 
diagnostics which do not support statistical 
report ing) 

inhibit program dropping of units 
execute autodrop code 
loop on test 

execute evaluation (on diagnostics which have 
evaluation support) 


HOF flag (Malt On Frror ) 

The HOF flag, when set, will cause DRS to e*ecute a 
'>ial t -on-error” seguenc e when an error is detected by me 
diagnostic. Execution of this sequence does not result in an 
actual processor halt, but returns DRS to command mode, ‘he 
exact process is.* 

1. When the error is reported to DRS, the error message(s) 
will be printed (unless printing has been inhibited). 

2 . DRS will return to command mode. 

3. The diagnostic will have been susoendei at the point of 
the error report to DRS and the unit being tested will be 
left in the state that it was in at the time of the call. 

After DRS has returned to command mode, the user may issue a 
F*ROCf ED command to resume diagnostic execution at the point where 
it was suspended. The user may also issue other commands as 
desired. 



« 


Page 3? 




I XXDP* System User 1 s 

j D Agnostic Runtime Services 

! 

i 

I i.QE f lag (LOOP On Error) 

i The L0€ flag, when set , will enable DRS error loopmg. yhe^ 

1 error looping is in effect, DRS will cause the diagnostic to 

continually re-execute the code that detected the error, toooing 
j remains in effect even if the symptoms that prompted the error 

1 report disappear. This allows for looping on intermittent 

errors. o stoo the looping, the user must type CTRl-C (*C> to 
! return DRS to command mode. 


IF.R Mag (Inhibit Error Reports) 


The IER flag, when set, causes DRS to inhibit all error reporting 
to the console terminal . While in effect, no messages will be 
sent to the operator except system error reports such as ILL INT 
(illegal interrupt) and end-of-pass reports. This feature is 
usually used in conjunction with error looping. It speeds up the 
test process and, in the case of hard copy terminals, saves 
paper. 


’BE flag (Inhibit Basic Errors) 

The IBE flag, when set, causes DRS to inhibit a portion of error 
reports. There are three levels of messages in an error report . 
This is illustrated below: 


I <E flag ( Inhibit extended Errors) 

The IXE flag, when set . causes DRS- to inhibit the extended error 
reporting only. The error message and basic reports will be 
pr inted. 


PR l flag (PRInter) 

The PRI flag, when set. causes DRS to redirect all messages to a 
l me printer. This does not apply to command prompts. 


PNT flag (Print Nctnber of Test > 

The PNT flag, when set, causes DRS to print the ix^nber of the 
rest being executed. , 

BOf flag (Bell On Error) 

The BOf flag, when set. causes DRS to issue a **CTRi-6 , \ or ‘’bell** 
character when an error is reported by the diagnostic* This will 
give an audible tone at the console terminal . This feature is 
usually used in conjunction with the message inhibit functions. 
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UAM Flag (UnAt tended Mode) 


The UAM flag, when set, prevents the use of manual intervention 
during testing. Manual intervention assumes that an operator is 
present to undertake any necessary action. The use of this flag 
allows the operator to start the diagnostic and let it run 
unattended. Wnen this flag is in effect, some testing will be 
inhibited. Refer to specific diagnostic documentation for a 
description of UAM flag effects in specific cases. 

1SR flag (Inhibit Statistical Reports) 


The ISR ,flag, when set, causes DRS to inhibit the printing of 
statistics by the diagnostic. This is an optional feature and 
not all diagnostics support statistics. Consult specific 
diagnostic documentation to determine whether or not a diagnostic 
has this feature. 

IDR Flag (Inhibit DRopping of units) 


The IDR flag, when set, causes DRS to inhibit the dropping 
(deselection) of units by a diagnostic. Diagnostics may deselect 
a unit from the test process if an error threshold is reached or 
if a serious error is detected. This flag allows the user to 
keep the unit selected, usually for the purposes of tracing the 
error. 

ADR Flag (autoDRop) 


The ADR flag, when set, causes DRS to execute the "autodrop" code 
in a diagnostic. The purpose of this code is to test for device 
ready" or "device available". If the unit being tested is not 
ready or available, it will be dropped (deselected). Not all 
diagnostics have autodrop code. Refer to specific diagnostic 
documentation to determine if a diagnostic does support this 
feature. 

LOT Flag (Loop On Test) 


The LOT flag, when set, causes DRS to continually execute the 
test(s) specified with the TEST switch. The initialize and 
end-of-pass code are not executed as in normal operation however. 

EVL Flag (EVaLuate) 


The EVL flag, when set, causes DRS to execute diagnostic 
evaluation code. This is an optional feature and you must refer 
to specific diagnostic documentation. 
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Section 4 — Table Building 


As stated in the beginning of the previous chapter, DRG uses 
hardware tables for unit information (such as register addresses, 
drive numbers or interrupt priority). Tables are also used for 
diagnostic-specific operational information (such as what data 
patterns to use for testing or whether or not to dc read-only 
testing). The specific information varies from diagnostic to 
diagnostic, so this section only seeks to provide the user with 
some background information on these tables. 

First, these tables must be constructed. They are constructed in 
three ways. One, the diagnostic is typically released 
(distributed) with only a "template" table for hardware data. 
This template contains default vaiues for hardware information in 
some cases. In any event, the actual tables must be built by the 
user. This is most often done by starting the diagnostic with 
the START command and specifying the hardware data as requested 
by the diagnostic. 

Two, the table may also be ’^rebuilt" by using SETUP (Chapter 
14). SETUP is an XXDP+ utility program that allows the user to 
build tables with jt actually running the diagnostic. The tables 
are stored with the diagnostic on the XXDP+ medium and are 
brought into memory with the diagnostic at runtime. The user may 
then initiate diagnostic operation without building tables. 

And three, the tables may have been built by the diagnostic 
programmer. These tables are already a part of the program image 
and may be used as they are or changed after a START command. 

The operational table, which is called the software (SW) table, 
may not be present in all diagnostics. If it is not present, you 
will rot be asked if you wish to change it. This is an actual 
storage area that has default data coded into it. 

All table-related questions have the same format: 

Question (type) [default^ ? 

The question may be something like "DRIVE NUMBER". The type is a 
one character code for the type of answer desired, enclosed in 
parenthesis. The possible types and codes are: 0 for octal, D 
for decimal, B for binary, A for ASCII and L for logical (Y or 
N). The question mark indicates that DRS is ready to accept the 
answer. If the answer is unacceptable for any reason, an error 
message will be typed and the user will be asked for the 
information again. 

When you answer the hardware questions, you are building entries 
in a table that describes the devices under test. The simplest 
way to build this table is to answer all questions for each unit 
to be tested. If you have a multiplexed device such as a mass 
storage controller with several drives or a communication device 
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with several lines, this becomes tedious since most of the 
answers are repetitious. 

To illustrate a more efficient method, suppose you are testing a 
fictional device, the XYll. Suppose this device consists of a 
control module with eight units (sub-devices) attached to it. 
These units are described by the octal numbers 0 through 7. 
There is one hardware parameter that can vary among units called 
the 'ti-factor' This Q-factor may be 0 or i. Below is a simple 
way to build a table for one XYll with eight units. The 
underlined portions are typed by DRS. 

ft UNITS (D) ? 8 

UNIT 1 

CSR ADDRESS (0) ? 160000 

SUB-DEVICE ft (0) ? 0 

Q-FACTOR (0) 0 ? 1 

<1 UNIT 2 

■I CSR ADDRESS (0) ? 160000 

SUB-DEVICE ft (0) ? 1 

Q-FACTOR (0) 1 ? 0 

UNIT 3 

CSR ADDRESS (0) ? 160000 

SUB-DEVICE ft (0) ? 2 

Q-FACTOR (0) 0 ? 

UNIT 4 

CSR ADDRESS (0) ? 160000 

SUB-DEVICE ft (0) ? 3 

Q-FACTOR (0) 0 ? 

UNIT 5 

CSR ADDRESS (0) ? 160000 

SUB-DEVICE ft (0) ? 4 

Q-FACTOR (0) 0 ? 

UNIT 6 

CSR ADDRESS (0) ? 160000 

SUB-DEVICE ft (0) ? 5 

Q-FACTOR (0) 0 ? 

UNIT 7 

CSR ADDRESS (0) ? 160000 

SUB-DEVICE ft (0) ? 6 

Q-FACTOR (0) 0 ? 1 

UNIT 8 

CSR ADDRESS (0) ? 160000 

SUB-DEVICE ft (0) ? 7 

Q-FACTOR (0) 1 ? 
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Notice that the default value for the Q-factor changes when a 
'non-default response is given. Be careful when specifying 
multiple units! 

As you can see from the above example, the hardware parameters do 
not vary significantly from unit to unit. The procedure shown is 
no 1- '.v'y efficient. T runtime services can take multiple unit 
specifications howe Let's build the same table using the 
multiple specificati eature. 

tt UNITS (D) ? 8 


UNIT 1 

CSR ADDRESS (0) ? 160000 

SUB-DEVICE tt (0) ? 0,1 

Q-FACTOR (0) 0 ? 1,0 IIZIIITI 

UNIT 3 

CSR ADDRESS (0) ? 160000 

SUB-DEVICE tt (0) ? 2-5 

q-factor (o) o ? o 

UNIT 7 

CSR ADDRESS (0) ? 160000 

SUB-DEVICE tt (0) ? 6,7 

Q-FACTOR (0) 0 ? 1 

As you can see in the above dialogue, the runtime services will 
build as many entries as it can with the information given in any 
one pass through the questions. In the first pass, tw entries 
are built since two sub-devices and Q-factors were specified. 
The services assume that the csr address is 160000 for both since 
it was specified only once. In the second pass, four entries 
were built. This is because fou*~ sub-devices were specified. 
The construct tells the runtime services to increment the 

data from the first number to the second. In this case, 
sub-devices 2, 3, A and 5 were specified. (If the sub-device 
were specified by addresses, the increment would be by 2 since 
addresses must be on an even boundary.) The csr addresses and 
Q-factors for the four entries are assumed to be 160000 and 0 
respectively since they were only specified once. The last two 
units are specified in the third pass. 

The whole process could have been accomplished in one pass as 
shown below. 


tt UNITS (D) ? 8 

UNIT 1 

CSR ADDRESS (0) ? 160000 

SUB-DEVICE tt (0) ? 0-7 
Q-FACTOR (0) 0 ? 0,1,0 1,1 


As you can see from this example, null replies (commas enclosing 
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a null field) tell the runtime services to repeat the last reply. 


N 3 
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Runtime Services Error Messages 


The following are DRS error messages. 
ERR HLT 


A ha It -on-error has occurred. DRS is now back at command mode. 
Halt-on-er^or only occurs if operator has specified this mode 
with a flag to DRS. 

’LL INTER nnn PC nnnnnn Ps nnnnnn 

An unexpected interrupt occurred through vector nnn. The Program 
Counter and Processor Status Word at the time of the interrupt 
are given. 

INSUFE MEM 

There is not enough memory space to store table information for 
the number of units that the user wants to specify. 

INVAL SWTCH FOR CMND 

The user specified a non-existent or non-applicable switch in the 
previous command. Refer to the table of switches in section 2 of 
Chapter 9. 

INVAL UNIT 

The user specified a unit that does not exist. 

? LOOKUP ERROR filnam 

This e r ror message actually comes from the XXDP+ monitor. If the 
file name is *T4SAA??.SYS, then the diagnostic being run re quires 
the DRS. but the DRS file is not on the system medium. Any other 
file name indicates that the diagnostic attempted to open a file 
that does not exist on the system medium. 

LOOP CHNG 

The range of the loop changed white looping on error was in 
progress. 

NOT HALTED 

The user attempted to enter a PROCEED command when the DRS had 
not executed a "halt-on-error" sequence. 

NO UNIT 


0039 
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There are no active units. Either no units have been specified 
or all units have been dropped. 

PASS ABORTED FOR THIS UNIT 


esting was prematurely ended for the current unit being tested, 
‘■fre is usually an error message from the diagnostic qwen prior 
this message. Refer to the specific diagnostic t, mentation 

the reason that the unit may have been aborted 

E RR AT : nnnnnn 


inrecognized TRAP instruction was execute p AP 

auction is used to communicate between fh* and 

This error should never occur in field ope i ease 

i r r t the problem if it does. 

# TOO BIG 


* h user specified a test number that is larger than the number 
t tests in the diagnostic program being run. 
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PART IV — XXDP+ Utility Programs 


There are five XXDP-*- utility programs described in this section. 
UPD1 and UPD2 art sed for manioulat ng files (moving files from 
one medium to another, loaded and saving files, etc.). The UPD] 
file is smaller and more primitive than UPD2 and is used on small 
systems with space limitations. PATCH is used for putting 
temjwarv changes (patches) into files. SETUP is used to 
i diagnostic programs that are compatible with the 

< - . ' - es . And finally, XTECO is a simple text editor 

for creating batch control files. There is a 
DXCL, for creating DEC/X11 exercisers. This 
•escribed in this manual. Please refer to the 
' ■ r for instructions on the use of DXCL. 
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Chapter 11 UPD2, 


UPD2 (Update Two) is a file manipulation utility program used for 
building XXDP+ media, copying files from one medium to another, 
deleting files from a medium, modifying files and other 
functions. The component name for UPD2 is "CHUP2?? UPD2 UTIL”, 
but for the benefit of the user, the program is released under 
its common name: UPD2. 

UPD2 runs in the lower part of memory and occupies about 6K 
words. It uses the runtime monitor for interfacing to the 
operator and loading the retrievable device drivers that it uses 
to accomplish device related functions. Since UPD2 requires 
these device drivers, the drivers you intend to use must be 
resident on the system medium and the system medium must be 
available (on-line) throughout your use of UPD2. There is one 
exception that is explained later in this chapter in conjunction 
with the DRIVER command. 

This chapter is organized as follows. First there is a brief 
description of how to start UPD2 and a list of commands. Next 
there are detailed descriptions of each command, grouped and 
ordered as in the list. And finally there is a list of error 
messages with a description of the meaning of each. New users 
should read the entire chapter. Persons familiar with UPD2 can 
use the index to find the description of a particular command. 
The error message section can be found quickly by referring to 
the index under "error messages (UPD2)”. 

Starting UPD2 

To start UPD2, type: 

R UPD2 

When the program has been successfully loaded by the monitor, it 
will type its name and a restart address and then type a prompt, 
to tell the user that it it is ready to accept commands. 
The commands are tabulated below and described in detail in this 
chapter of the manual. 
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UP02 Commands 


file Manipulation 


DIR 

PIP 

FILE 

DEL 

REN 

give directory of specified medium 
transfer a file or files 
transfer a file or files 
delete a file or files 
rename a file 

F i le Modification 

CLR 

LOAD 

MOD 

XFR 

HI CORE 
LOCORE 
DUMP 

clear UPD2 program buffer 

load a program 

modify file image in memory 

set transfer address 

set upper memory limit for dump 

set lower memory limit for dump 

dump a program image 

New Medium Creation 

ZERO 
SAVM 
SAVE 
COP 7 

initialize a medium 
save a monitor on a disk 
save a monitor on a tape 
copy entire medium 

Miscellaneous 

ASG 

DO 

READ 

EOT 

DRIVER 

assign a logical name to a device 
execute an indirect command file 
read a file to check validity 
write logical end-of-tape mark on a tape 
load a device driver 

Returning 

to Monitor 

BOOT 

EXIT 

bootstrap a device 

return control to the runtime monitor 

Printing 


PRINT 

TYPE 

print a file on the line printer 
type a file on the console terminal 
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File Manipulation 


The tile manipulation commands are used to maintain XXDP+ media. 
Files may be transferred from medium to medium, deleted from a 
medium or renamed. A directory, or list, of files on a medium 
may be obtained. 

DIR 

The directory command is used to obtain a directory, or list, of 

files on a specified medium. The user can specify where the 

directory is to go (console terminal, line printer or file) and 
what form the directory is to take (long or short). The format 
of the command is: 

DIR CCdevo:3Cof i leDC/QD=3Cdevi : JCi f i le3C/QJ£/FJC/83C/l3 
where, 

devo - output device; default is console terminal unless 
ofile is specified or the is used, in which case the 
system device is default; device is assumed to be online 
and write-enabled 

ofile - name of file for directory (devo must be a 

f i le-structured device); default is DIR. TXT; if a file 

already exists with the specified name, it is autodeleted 

/Q - do not rewind output medium prior to beginning 
directory search for file with same name as ofile (for 
tape units only); rewind if switch not specified 

devi - device from which to take directory; system device 
is default; device is assumed to be online and ready 

ifile - files to be listed in directory; wildcards are 
legal; default is *.* 

/Q - do not rewind input medium prior to starting directory 
operation (tape devices only); rewind if switch not 
specified 

/F - give short form of directory; long form if switch not 
spec i f i ed 

/B - list number of free blocks left on input medium (random 
access devices only) 

/l - send directory to a line printer (parallel printers 
only) 

There are samples of both forms of the directory on page 16 of 
this manual. Examples of the directory command: 
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DIR DX0:DISK.TXT=MM0:/Q 

The directory of tiles on MMO will be written into a file called 
‘BISK.TXT" on DXO. The tape will not be rewound during the 
ope rat ion. 


DIR =DR1 ■•.BIN 

A directory of all files with 'BIN" extensions on DR1 will be 
written into a file called "DIR. TXT'* on the system device. 

DIR 

A directory of all files on the system device will be typed at 
the console terminal. 

DIR = 

A directory of all files on the system device will be put into a 
file railed "DIR. TXT" on the system device. Please take note of 
the efrect of the equals sign on the operation of the directory 
command. 


DIR DYOr/F/L 

A short form directory of all files on DYO will be printed on the 
line printer. 


PIP - FILE 


The PIP and FILE commands are used to transfer a single file, or 
multiple files, from one medium to another. There are two 
differences between these commands. The FILE command allows 
autodeletion; the PIP command does not. You may specify an 
output file name with the PIP command; you may not with the FILE 
command. 

Autodeletion is simply the removal of a file from the output 
.nedium if it has the same name and extension as the file being 
transferred. If you attempt to transfer a file when the name 
already exists on the output medium using the PIP command, the 
file is not deleted, the transfer does not occur and a warning 
message is printed. If several files are being transferred, only 
those that do not have names and extensions that match already 
existing files on ,the output medium are transferred. If a FILE 
command is used, all files are transferred regardless of what 
files exist on the output medium and any files on the output 
medium that have names and extensions matching those of files 
being transferred are deleted prior to the transfer. The 
operator is not notified of autodeletions. 

The PIP command may be used to rename a file during the transfer 
process since output file spec if ications are allowed. The FILE 
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command never accepts output file specifications and files will 
retain their names and extensions as they are transferred. 

The format of these commands are: 

PIP Cdevo: JCof i le3C/Q3=Cdevi :3Cif i le3C/Q3[/N3 
FILE [devo:3C/Q3=Ldevi :3Ci f i le3C/Q3C/N3 


where. 

devo - output device; system device is default; device is 
assumed to be online and write-enabled 

ofile - file name for output file; wildcards are permitted, 
in which case the input files will be renamed to match 
the output specification (please refer to the examples 
below); default is *.*; if file already exists on 
output device, transfer will not occur; NOT USED WITH 
FILE COMMAND 

/Q - do not rewind output medium prior to directory search 
for already existing file (tape devices only); rewind 
after each file if switch not specified 

devi - input device; default is system device; device is 
assumed to be online and ready 

ifile - input file name; wildcards are permitted; default 
is *.*; file(s) specified must exist 

/Q - do not rewind before directory search for first file 
(tape devices only); rewind if switch is not specified 

/N - do not type name of each file as it is found; type 
each name if switch is not specified 

Examples of the PIP and FILE commands: 

PIP DX0:NEW.8IN=DR1 .-ZZZZZZ.BIN 

The file "ZZZZZZ.BIN" wi U be transferred from DR1 to DXO and 
named ’NEW. BIN". The transfer will not occur it ’ NEW. BIN’ ' 

already exists on DXO. 

FILE DX0:=DR1 .-ZZZZZZ.BIN 

The file "ZZZZZZ.BIN will be transferred from DR1 to DXO. It 
will replace a file of the same name on DXO if such a file 
exists. 


PIP =DD0:XMQNC0.LJ8 

The file "XMONC0.L 18" wi l l be transferred to the system device 
from DDO. The name will not be changed. If "XMONCO.LIB" already 
exists on the system device, the user will be given an error 
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indication and the transfer will not occur. 
FILE =DDO:XMONCO.LI8 


This command has the same effect as the command in the previous 
example with the exception that if "XMONCO" already exists on the 
system device, it will be deleted prior to the transfer. 

PIP DKl :=DK0: 

All files on DKO will be transferred to DKl. Any files that 
already exist on DKl will not be transferred and the operator 
will be notified. The remaining files wilt be transferred. 

FILE DKl :=DK0: 

In this case all files on DKO will be copied to DKl, regardless 
of what files already exist on DKl. This command provides a 
convenient method of putting updated files onto an existing XXDP+ 
medium. 


PIP MM0:FILE??.*= 

All files on the system device wit l be transferred to MMO and 
RENAMED to have the characters 'TILE" replace the first four 
characters of the original name. Be careful if you use wildcards 
on the output specification! 


DEL 

The DELETE command is used to remove a file, or files, from an 
XXDP+ medium. The actual process for deletion is to remove the 
file name from the directory and deallocate the physical blocks 
used by the file. The format of the command is: 

DEL dev: if i le[/NJ[/Qj 

where, 

dev - device where file resides; device is assumed to be 

online and write-enabled; there is no default 

ifile - file(s) to be deleted; file must be on device 

specified; extension must be specified (unless file has no 
extension); wildcards are accepted 

/N - inhibit printing of file names as they are deleted; if 
switch is not specified, names will be printed 

/Q - do not rewind before searching for file(s) (tape devices 
only); • ? f switch is not specified, tape will be rewound 
prior to searching for each file to be deleted 

Examples of the delete command: 



J 4 


SEQ 0048 


XXDP+ 

XXDP+ 


System User's Manual Pa 9 e ^8 

Utility Programs — UPD2 


DEL MM0:XYZ001 . TXT/Q 

The file named ' ’XYZOOI . TXT” on MMO will be deleted. The search 
tor the file will begin at the point where the tape is currently 
positioned (the no rewind switch has been specified). An error 
wilt be reported if the device is not online and write-enabled or 
if the file does not exist. 

DEL *.0LD 

All files on the system device with "OLD" extensions will be 
deleted. An error will be reported if the device is not online 
and write-enabled or if there are no filed with "OLD" extensions. 


REN 

The rename command is used to change the file specification of an 
existing file without doing a transfer. The name of the file as 
recorded in the directory is changed, but there is no movement of 
data. The format of the command is: 

REN Cdev:3newnam=Cdev:3oldnam 


dev - device where file to be rer amed exists; default is 
system device; device is assumed to be online and 
write-enabled; device must be same for both input and 
output 

newnam - new file specification; file with same specification 
must not exist on device; wildcards are accepted 

oldnam - current file specification; file must exist on 
device; wildcards are accepted 

Examples of the rename command: 

REN DX1 :DIA6.0LD=DX1 :DIAG.8IN 
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F i le Modi f icat ion 


One of the prime functions of UPD2 is the modification of binary 
files. When a diagnostic program is found to have a deficiency., 
one of the corrective measures taken is to issue a DEPO or "patch 
order". This is a temporary change to a released program. UPD2 
is one of the means of implementing these temporary remedies. 
The program in question is loaded from an XXDP+ medium into an 
area in memory called the program buffer. This area lies in the 
physical memory space between the monitor and UPD2 and its size 
is determined by the amount of memory in the system. The size is 
equal to the system size minus 8K words, but no larger than 2 OK 
words. The program image, now resident in memory, may be 
modified and then pul back onto an XXDP+ medium ("dumped"). The 
transfer address and load image size may also be metered by the 
user at this time. 

The next seven commands relate to this function of UPD2. In the 
descriptions of these commands, locations within a program that 
has been loaded into the program buffer are referred to as 
"virtual locations" since their addresses are relative to the 
first physical location in the program buffer L J not the first 
physical memory location as would be the case if the program had 
Been loaded by the monitor. 

The location addresses given in a DEPO (Diagnostic Engineering 
Patch Order) are treated as virtual when using UPD2. For 
e<ample, if the DEPO says to modify location 1002, that will be 
tne virtual location you will refer to in the MOD command. If 
the program has been loaded by the monitor however, 1002 would be 
an absolute address in memory, not a relative location in the 
program buffer. 

The file modification process applies to image (8JC or BIN) files 
only. The process, briefly, consists of the following steps: 

1. Load the file into the program buffer with the LOAD 
command. 

2. Change the size of the image, if necessary, with the 
HICORE and LOCORE commands. 

3. Modify the contents of the desired location(s) with the 
MOD command. 

4. Modify the transfer address, if desired, with the XFR 
command. 

5. Write the image onto media with the DUMP command. 

These commands are detailed in the following sections. A sample 
file modification is given after the descriptions. 

CLR 

The clear command clears the program buffer into which programs 
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are loaded for modification. This command allows the user to 
assure that unused locations in a program are set to zero when 
th' program image is dumped to a medium. The format of the 
command is: 


CLR 


LOAD 

The load command is used to load a binary file into memory for 
the purpose of modifying the program image. As the file is 
loaded, a checksum is computed and compared with a checksum 
stored with the file. The command format is: 

LOAD Cdevi :Jif i leC/NJC/OJ 


where, 

devi - device from which to load the file; default is the 
system device; device is assumed to be online and ready 

ifile file to be loaded; no default accepted 

/N - inhibit printing of upper and lower memory limits and 
file name found (if wildcard used) 

/Q - inhibit rewind before searching for file (tapes only) 

Wildcards are permitted in the file specification, but the user 
should take care when doing so. The data in the program buffer 
will be the result of the overlays of each file found. The 
program buffer is not cleared between loads and the unused 
locations for the cast file loaded will not necessarily contain 
zero's for contents. The wildcard feature is really only useful 
for doing file sanity checks where the user is interested in 
verifying that files are not corrupted. 

Aft e che load has been successfully completed, UPD2 will print 
the transfer address and core limits (the lowest and highest 
virtual memory locations used by the program). These parameters 
may be altered by the user as described in subsequent command 
descriptions. Example: 

LOAD DXO:PROG1.8JN 

XFR: C00001 CORE: 000000,020000 

This command is also used to load an XXDP+ monitor image into the 
program buffer. This must be done as part of the media build 
process. The section on New Medium Creation in this chapter and 
Part VI of this manual describe this process. 
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MOD 

The modify command is used to alter the contents of one or more 
virtual memory locations in a program that has been loaded by 
UPD2. The format of the command is: 

MOD nnnnnn 

, where nnnnnn is the octal address of the virtual memory location 
where the contents are to be modified. UPD2 will respond by 
typing the address and the current contents. It will then wsit 
for the user to either type new contents or accept the the 
current contents by typing a carriage return”. If the user 
wishes to modify, or examine, two or more consecutive virtual 
memory locations, he or she should type a “line feed” after 
modifying each location. Examples: 

MOD 2460 

002460 770 771 (CR) 

The user has modified v'rtual memory location 2460. 

MOD 12004 
012004 01 2736 (CR) 

The user has examined, but not modified, virtual location 12004. 
MOD 1220 

001220 120 167CLF) 

001222 120 1234(CR) 


The user has modified two consecutive virtual memory locations 
(1220 and 1222). 


XFR 

This command is used to modify the transfer address in the 
program that has been loaded. The file created by the DUMP 
command will have this transfer address. This is address of the 
location to which control will be transferred when the program is 
started. 

After the user has entered this command, UPD2 will print the 
current transfer address. If the user does not wish to alter the 
transfer address, he or she should immediately type a “carriage 
return”. The format of the command is: 

XFR 


Examples of this command: 
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XFR 

000200 001000 

The user has changed the transfer address from 200 (octal) to 
1000 (octal). 

XFR 

002000 'CR) 

The user has not altered the transfer address. 


HI CORE 


The high core command is used to alter the address of the highest 
virtual memory location that will be transferred during a dump 
operation. The default location is printed after the LOAb 
command. The format of this command is: 

HI CORE 

The address of the highest virtual memory location to be used 
during a dump operation will be printed. UPD2 will then wait for 
the user to alter or accept the location. T he user may enter a 
new location by typing the octal address or accept the location, 
as is by typing a carriage return". This address must be above 
that of the lowest virtual location (low core) and below that of 
the top of the program buffer. 

Examples: 

HI CORE 
40000 45000 

The user has changed the upper virtual location from 40000 to 
45000. 

hi CORE 
100000 (CR) 

The user has allowed the upper location to remain as 100000. 


LOCORE 


The low core , ownand is us d to alter the address of the lowest 
virtual memory location that will be transferrec in a dump 
operation. The default location is printed after the load 
operation has been completed. The format of this command is: 

LOCORE 


Examples: 
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L0C0RE 
000200 0 

The user has modified the low memory address to zero. 

10C0RE 
•00000 20 

> low memory address to 20 (octal). 


tc. write the program image in the 
■> file on a medium. The imavge size is 
and lower memory limits displayed by the 
. -narids . A transfer address will be put into 

f. f • s s can be examined and altered with the XFR 

c v /*v > v t of this command is: 

DUMP Edev.Oof i leC/QO 


dev # - device to which file is to written; default is system 
device; device is assumed to online and write-enabled 

ofile - file name for binary file; wildcards are not accepted; 
file with specified name must not already exist on device 

/Q - inhibit rewind before searching for logical end-of-tape 
(tapes only) 

Examples of the dump command: 

DUMP DY0: ZRLAA1 .BIN 

The program image will be written to DY0 and given the file name: 

* 7RLAA1 .8JN". 

DUMP FILE3.8IC 

The image will be written to the system device and given the 
spec i f i ed name . 

Sample Modification 

The following sample file modification illustrates the use of the 
preceeding se conwiands. It is based on the following patch 
for a fictitio diagnostic named ZXXX80.8IN: 
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Location 

Old Contents 

New Contents 

1224 

106701 

240 

1226 

177660 

240 

1452 

376 

374 


The UPD2-user dialogue used to accomplish this is shown below. 
The underlined portion is that typed by UPD2. (LF) and (CR) 
refer to line feed and return. 

.R IJPD2 


CHUP2B0 XXDP+ UPD2 UTILITY 
RESTART ADDRESS: 002432 


♦LOAD ZXXXB0.BIN 

XFR : 000001 CORE: 000200. 027230 


♦MOD 1224 
001224 106701 

001226 177660 

240 an 

240(CR) 

♦MOD 1224 
001224 000240 

001226 000240 

(LF ) ~ 
(CR) 

♦MOD 1452 
001452 000376 

374 (CR) 

♦MOD 1452 
001452 000374 

(CR) “ 

♦DUMP ZXXXB1.BIN 



★ 

The user examines locatTons previously modified in order to 
verify the changes. The user also renames the file to reflect 
the patch level. 
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New Medium Creation 


The commands described in this section are used to create new 
XXDP+ media. The build process is described in detail in Part VI 
of this manual. The user should familiarize him/herself with 
t^ese commands before proceeding to Part VI. 

ZERO 

The zero command initializes a medium by clearing the bit map 
(random access devices) or writing an end-of-tape mark 

(sequential access devices) and placing an empty directory on the 
medicm. CAUTION: all data on the medium prior to a zero 

operation is irretrievably lost after the operation. UPD2 makes 
no attempt to determine what is on a medium and will destroy 
customer data. A warning is printed whenever this command is 
invoked, stating which device is involved. The user must then 
verify that the zero operation is to take place. The format of 
the command is: 

ZERO dev: 

There is no default for the device. The device must be online 
and write-enabled. The following warning will be issued after 
the command is entered: 

USER DATA ON dev WILL BE DESTROYED! 

PROCEED? ( Y/N/CR=N) 

The only answer that will confirm the user’s intent to carry on 
is ”Y”. 

There will be an additional warning message if you specify the 
system device in the ZERO command. 

ZERO SYSTEM DEVICE 

YOU MAY NEED AN ADDITIONAL D8IVER 

PROCEED? (Y/N/CR=N) 

If you wish to proceed with the process, you must type a "Y”. 
The meaning of the warning is that you must assure the presence 
in memory of two drivers, one for the system device and one for 
the device from which files will be moved to the new media in the 
system device. To assure that the necessary drivers are in 
memory, use the DRIVER command. 


SAVE - SAVM 


The save commands are used to place a bootable monitor on a 
medium. The SAVE command is used for sequential access devices 
and the SAVM for random access devices. (Sequential access 
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devices are MM, MT, MS and CT.) The command places the 
appropriate secondary bootstrap on the boot block and places the 
monitor file on the medium in a predetermined section. The 
monitor image file (e.g.; HMDKBO. SYS) must have been loaded into 
•the program buffer using the load command. See example below. 

j Refer to Chapters 18 and 19 for details on building XXDP+ media. 

| The medium need not be initialized with the zero command if the 

| medium is already XXDP+ compatible. In this case only the 

j monitor and bootstrap on the medium prior to the save operation 

are lost. All other files are preserved. 

i The format of the commands are: 

| 

I SAVE dev: 

| SAVM dev: 

| 

where dev: is the device with the medium that is to be made 
bootable. The device must be online and write-enabled. The 

device must be sequential access (e.g.; magtape) when using the 
SAVE command. It must be random access (e.g.; disk) when using 
the SAVM command. 

j Example: 

LOAD HMDX??.SYS 

( SAVM DX1: 


COPY 

The copy command is used to copy the entire contents of one 
medium to another identical medium (e.g.; RP06 to RP06). The 
copy process can take two forms. The first is an "image copy". 
This is a block-for-block transfer and is very fast since all 
available memory is used as a buffer. If the device is a bad 
block device, there is a chance that a bad sector may be 
encountered during the copy process. In this case the process 
wilt be aborted. You will then have to use the second form, 
"file copy". This is slower since only one block is transferred 
at a time. In both cases, the former contents of the medium are 
destroyed. There is no check for medium type and customer data 
could be lost. Be careful! There will be a warning message as 
shown below. The copy will proceed only if a ,m y m is typed. 
The format of the command is: 

COPY devo:=devi: 

USER DATA ON devo WILL BE DESTROYED! 

PROCEED? (Y/N/CR=N) 

where devo and devi are the output and input devices 
respectively. The two devices must be the same type. Both 
devices must be online and the output device must be 
write-enabled. 
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Miscellaneous 


ASG 

The assign command is used to assign a logical unit number to a 
device. The device can then be referenced by this number in 
ensuing UPD2 commands. The format of the command is: 

ASG dev:=n 


where, 

dev - device to be assigned 
n - logical unit number (0-7) 

The primary use for the assign command is to facilitate the use 
of the DO command and indirect command files (see next section). 

Example of assign command: 

ASG DKO : =0 

PIP 0:=DK1.*.CCC 

FILE 0:=MM0: FILE. NEW 


DO 

The do command is used to execute an indirect command file for 
UPD2. This file is a text file that contains one or more 
commands executable by UPD2 with the exception of r XJT The us_ j r 
may create a command file that accompl ishes some common tack such 
as building new media. This saves time and effort on the part of 
the user since he or she need not en^er each command by nand. 
The format of the command is: 

DO file. ext 

The specified file must be on the system device, therefore you 
cannot specify a device. 

There are two functions available in the indirect command file in 
addition to the normal set of UPD2 commands. First, any command 
line beginning with a semicolon (;) will be treated as a comment. 
That is, no action will be taken; the line is merely printed. 
Second, a command line beginning with a dollar sign ($) will also 
be treated as a comment, except the processing of the command 
file will cease after the line is printed and resumed when a 
“Control X“ is typed. (Control X is typed by depressing the X 
key while holding the CTRL down.) This second function can be 
used to stop activity while the operator performs some required 
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task such as mounting a new medium or placing a device online. 

The file can be made more global in scope by using logical unit 
numbers instead of device names in tne commands. The user can 
then assign logical unit numbers prior to using the indirect 
command tile using the assign command. The example below 
illustrates the combined use of the two command". 

Sample Command File: RMBLD.TXT . _ 

ZERO 1 : 

LOAD 0HMDR77.5YS 
SAVM 1 : 

FILE 1:=0:*.SYS 
FILE 1 :=0: UPD2.BIN 

The above file can be used to build the XXDP+ System on any 
RM02/3 using any other XXDP+ medium. (Note that the command line 
containing a ’V only is required to verify the zero process. 
See the zero command description.) The process for doing this is: 

.R UPD2 
*ASG DR2:=1 
*ASG WT0:=0 
*D0 RMBLD.TXT 
*EXJT 

The underlined portion of the above example is that typed by 
JPD?. The remainder is typed by the user. 


READ 

The read command is used to check device and media integrity. 
Each block of the file specified in the command is read into 
memory and a checkscn is calculated. The computed checksum is 
compared to the checksum stored with the file. The format of the 
command is: 


READ Cdev: Jif i leC/NJC/Qj 

where. 

dev - device from which file(s) are to be read;default is 
system device; device must be online 

ifile - file(s) to be read; wildcards are accepted 

/N - do not print name of each file as it is read 

/Q - do not rewind before searching for specified files (tape 
devices only); rewind will occur if switch is not specified 


EOT 
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The end-cf-tape command is used to place a logical end-of-tape 
marker on a tape at the current position. Note, the tape is not 
rewound. All files after the current position will no longer be 
accessible. The marker consists of two consecutive tape marks. 
Any data beyond this point on the tape is lost. The format of 
the command is: 

EOT dev: 

Tne device must be a tape unit. The system device, if a tape 
unit, is the default device. 


DRIVER 


The driver command is used to explicitly load a read/write device 
driver into memory. Up to two drivers may be loaded. If a third 
driver is loaded, one of the drivers currently in memory will be 
lost. If a requested driver is already in memory, no action is 
taken. The format of the command is: 

DRIVER drivert/driverj 

where ' ’driver" is the two character device name (e.g.; DX = 
RX01 ) . The list of supported devices and their names is in 
Chapter 16. Note that two devices may be specified with one 
c ommand . 

DRIVER D> : /OK : 

T ne purpose of the driver command is to allow a user to build 
XXDP+ media with limited resources. If the system device is 
required for building a new medium, the user can load the drivers 
required, remove tne system medium, mount the new medium and 
build XXDP+. 
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Returning to Monitor 


There are two commands that allow the user to return control to 
the monitor. These are described below. 

BOOT 

The bootstrap command is used to start the monitor in the same 
manner as the hardware bootstrap. The purpose of this command is 
to allow the user to boot a device other than the original system 
device. The booted device is now the system device. The format 
of the command is: 


BOOT dev: 

The device must have a bootable medium mounted. The boot process 
consists of loading the firs v physical block (boot block) into 
the first 2 56 (decimal) words of memory and starting execution at 
location 0. 

EXIT 

The exit command is used to return control ’•o the runtime 
monitor. The format of the command is: 


EXIT 


* 
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I 

i 

I Printing 


There are two commands to output textual information from files. 


PRIN T 


The print command is used to r^ad textual informat ’on from a file 
and output it to a line printer. The file must contain text in 
ASCII format. The format of the command is: 

PRINT Cdev.Oi f i leC/OJ 


where, 

dev - device where file is located; default is system device; 
device must be online 


ifile - file to be printed; must exist and contain text 

/Q - do not rewind before searching for specified file (tape 
devices only'; rewind will occur if switch is not specified 

Example: 

PRINT MT1 :HELP. TXT/Q 

The file 'ViELP.TXT" will be read from the tape on MTO and printed 
on the line printer. The search for the file will begin at the 
current tape location; no rewind will occur. 


TYPE 

The type command is used to read textual information from a file 
and output it to the console terminal. The file must contain 
text in ASCII format. The format of the command is: 

TYPE Cdev:3ifileC/Q3 

where, 

dev - device where file located; default is system device; 
device must be online 

ifile - file to be typed; must exist and contain text 

/Q - do not rewind before searching for specified file (tape 
devices only); rewind will occur if switch is not specified 

Example: 


TYPE SYSTEM. CCC 

The file "SYSTEM. CCC’* wi l l be read from the system device and 
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Error Messages 


The error messages that could be typed during UPD2 operation are 
listed alphabetically below. Tne lower case letters "device 
error" refer to a series of specific errors that can be detected 
by the device drivers. The possible errors are listed after the 
error messages. 

? CHECKSUM ERROR 

Each block in a binary file has a checksum storeo in it. If 
the checksum calculated while reading the block does not mat h 
the checksum in the block, this error will be printed. Try 
the operation again, but the file was probably corrupted. 

? device error 

Each read/write device driver may detect an error during an 
operation. The driver will report the type of error and 
return control to the program being used. This program will 
append any additional information as shown in the next six 
error messages. The errors that can be reported by drivers 
are: READ ERROR and WRITE ERROR. 

? device error ON INPUT DEVICE 

The specified error occurred on the input device specified in 
the last operator command. If the error persists, the media 
or the hardware may be bad. Try running diagnostics for the 
specific device. 

? device error ON OUTPUT DEVICE 

Same as above, except output device has problem. 

? device error ON INPUT DEVICE DIRECTORY 

The specified error occurred while accessing the directory on 
the input device specified in the last operator command. 
There may be problems with either the device or the media. 
Try running diagnostics for the device. 

? device et i or ON OUTPUT DEVICE DIRECTORY 

Same as above, except the output device specified in the last 
operator command is involved. 

? device error WHILE LOADING DRIVER FOR dev 

The specified error occurred while the driver for the 
specified device was being loaded into memory. 
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? device error WHILE READING filename 

| 

i The specified error occurred while the specified file was 

I being read. 

! ? DEVICE FULL 

The capacity of the output device has been exceeded, for disk 
devices (random access), there are not enough physical blocks 
remaining to store the file. Any blocks allocated during the 
attempt to write the file are deallocated. F,.-r tape devices 
(sequential access), the physical end-of-tape mark was reached 
while the file was being written. In both cases, no file is 
created. Delete some existing files or use another medium. 

? DIRECTORY FULL 

There are no remaining entries in the directory and the name 
of the file and other data cannot be entered. No file is 
created. Delete some existing files or use another medium. 

? UNEXPECTED END-Of-FILE 

The logical end of a file was encountered before it was 
expected. The f’le in question is corrupt. * 

? FILE ALREADY FXISTS 

The name of the file specified for output matches that of a 
file that already exists on the output medium. Delete the old 
file or use a different name. 

INVALID ADDRESS 

There are three operations that can cause this error. One, 
when using the MOD command to modify a virtual location, the 
address of the location given was odd or not within the upper 
and tower core limits. Two, the address given in a LOCORE 
command was higher than the current high core limit. And, 
three, the address given in a H1C0RE command was lower than 
the current low core limit. 

? INVALID COMMAND * 

The last command specified was not one of the legal commands 
for U PD2. Re-enter the command properly. 

? INVALID DEVICE 

This error has a number of causes, depending on the command 
being used. For file related commands (DIR, COPY, ZERO, SAVE. 
SAW, DEL, BOOT and EOT), one of the devices specified is not 
t i Le-st rue tured (tike paper tape). For EOT, the device is a 
.ion- tape device. For COPY, the specified devices are not 



Page 64 


S EG 0064 




N 5 


SEQ 0065 


XXDP+ System User s Manual Page 65 

XXDP* Utility Programs — UPD2 


identical types. For SAVE, the device is not a sequential 
access device. For SAVM. the device was not a random access 
device. 

? INVALID FILENAME 

The filename specified in the last command was invalid. Check 
the command and re-enter properly. 

? INVALID NUMBER 

A number specified in the Ust command was not entered 
properly. Possible problems *re: not a number (e.g., 12e4) 

or not oroper radix (e.g., 1292 is not octal). 

? INVALID SWITCH 

The last command was entered with a switch thct is not 
recognized by UPD2. Pe-enter the command properly, 

? LOGICAL DEVICE NOT ASSIGNED 

An attempt was made to use a logical unit number without first 
assigning it to a device. (See Aoo command.) 

? NOT FOUND 

The file specified for input in the last command was not found 
on the device specified. 

? NO T FOUND : HDxx??SYS 

The driver for device ”xx'‘ was not c ound on the system medium. 
This message is printed by the monitor driver which is used to 
load device drivers for UPD2. Transfer the required driver 
file *o the system medium. 

? SPECIFY DEVICE 

The last command specked does not allow the use of default 
device specificatit , . Re-enter the command with the 
device(s) explicitly specified. 

? OVERFLOW 

An attempt was made to load too large a program into the 
program buffer. 

? SYNTAX ERROR 

The last command was entered improperly. Re-enter the .u. land 
properly. 
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Chapter 12 


UPD1 


UPD1 (Update One) is a tile modification program that duplicates 
some of the functions in UPD2 (Chapter 11). It is used 
exclusively for modi tying binary files and, because of its small 
size, can be used with larger programs than UPD2. The component 
name for UPD1 is "CHUP1?? UPD1 UTIL”, but for the benefit of the 
user, the program is released under its common name: UPD1 . 

UPD1 runs in upper memory and overlays part of the monitor. This 
means that you cannot exit from tne utility to the monitor 
directly. UPD1 requires the retrievable device drivers that 
reside on the system medium. The system medium must therefore 
remain online and r ady throughout your use of UPD1 . UPD1 can 
only use one device at a time. It cannot trans.er files. 

This chapter is organized as follows. First there is a brief 
description of how to start UP01 and a list of commands (pg. 
44). Next there are detailed descriptions of each command. And 
finally there is a list of error messages with a description of 
each. For a quick reference for error messages, look in the 
’ J ex under "error messages (UPD1)". 

Starting UPD1 


To start UPD1 , type: 

R UPD1 

When the program has been successfully loaded by the monitor, it 
will type its name and restart address and then type a prompt, 
to tell the user that it is ready to accept commands. The 
commands are tabulated below and described in detail in this 
chapter. 


CLR 

LOAD 

MOD 

XFR 

HI CORE 

LOCORE 

DUMP 

DEL 

BOOT 


UPD1 Commands 


clear UPD1 program buffer 

load a program 

modify file image in memory 

set transfer address 

set upper memory limit for dump 

set lower memory limit for dump 

dump a program image 

delete a file 

bootstrap a device 
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File Modification 


The function of UPD1 is to modify binary files. When a 
deficiency is found in a diagnostic program, one of the 
corrective measures taken is to issue a DEPO or “patch order". 
This is a temporary change to a released program. UPD1 is one of 
the means of implementing these temporary remedies. The program 
in question is loaded from an XXDP+ medium into an area in memory 
called the program buffer. This area lies in the physical memory 
space between the UPD1 program and the XXDP+ monitor. The 
program image, now resident in memory, may be modified and then 
put back onto an XXDP+ medium (“dumped”). 

The next seven commands relate to this function of UPD1 . In the 
descriptions o * these commands, locations within a program that 
has been loaded into the program buffer are referred to as 
“virtual locations" since their addresses are relative to the 
first physical location in the program buffer and not the first 
physical memory location as would be the case if the program had 
been loaded by the monitor. 

The location addresses given in a DEPO (Diagnostic Engineering 
Patch Order) are treated as virtual when using UPD1 . For 
example, if the DEPO says to modify location 1002, that will be 
the virtual location you will refer to in the MOD command. If 
the program has been loaded by the monitor however, 1002 would be 
an absolute address in memory, not a relative location in the 
program buffer. 

The file modification process applies to image (8IC or BIN) files 
only. The process, briefly, consists of the following steps: 

1. Load the file into the program buffer with the LOAD 
command. 

2. Change the size of the image, if necessary, with the 
HI CORE and LOCORE commands. 

3. Modify the contents of the desired location(s) with the 
MOD command. 

A. Modify the transfer address, if desired, with the XFR 
command. 

5. Write the image onto media using the DUMP command. 

CLR 

The clear command clears the program buffer into which programs 
are loaded for modification. This command allows the user to 
assure that unused locations in a program are set to zero when 
| the program image is dumped to a medium. The format of the 

command is: 








CLR 
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LOAD 

The load command is used to load a binary file into memory for 
the purpose of modifying the program image. The command format 
i s : 

LOAD Cdevi.Oifile 

where, 

devi - device from which to load the file; default is the 
system device; device is assumed to be online and ready 

ifile - file to be loaded; no default accepted; wildcards 
are not allowed 

The program buffer is not cleared between loads and the unused 
locations for the last file loaded will not necessarily contain 
zero’s for contents. 

After: the load has been successfully completed, UPD1 will print 
the transfer address and core limits (the lowest and highest 
virtual memory locations used by the program) . These parameters 
may be altered by the user as described in subsequent command 
descriptions. Example: 

LOAD DXO:PROG1.8IN 

XFR: 000001 CORE: 000000,020000 


MOD 

The modify command is used to alter the contents of one or more 
virtual memory locations in a program that has been loaded by 
UPD1 . The format of the command is: 

r*0D nnnnnn 

, where nnnnnn is the octal address of the virtual memory location 
where the contents are to be modified. UPD1 will respond by 
typing the address and the current contents. It will then wait 
for the user to either type new contents or accept the the 
current contents by typing a carriage return". If the user 
wishes to modify, or examine, two or more consecutive virtual 
memory locations, he or she should type a "line feed" after 
modifying each location. Examples: 

MOD 2463 

002460 770 77UCR) 

The user has modified virtual memory location 2460. 


IOD 12004 

012004 01 2736 (CR) 


XXDP+ 

XXDP+ 


E 6 

System User's Manual Page 69 

Utility Programs — UPD1 SEQ 0069 


The user has examined, but t modified, virtual location 12004. 
MOD 1220 

001220 120 1 67 < L F ) 

001222 120 1234(CR) 


The user has modified two consecutive virtual memory locations 
(1220 and 1222). 


XFP 

This command is used to modify the transfer address in the 
program that has been leaded. The transfer address is the 
address at which a program will be started after being loaded 
into memory. The file created by the PUMP command will nave this 
transfer address. This is address of the location to which 
control will be transferred when the program is started. The 
transfer address is always set to "1" when a program is loaded 
into the program buffer. (The transfer address in the file 
loaded from is not altered.) A transfer address of ”1” is 
equivalent to a transfer address of "200”. 

After the user has entered this command, UPD1 will print the 
current transfer address. If the user does not wish to alter the 
transfer address, he or she should immediately type a "carriage 
return". The format of the command is: 

XFR 


Examples of this command: i 

| 


XFR 

000200 001000 

The user has changed the transfer address from 200 (octal) to 
1000 (octal). 


XFR 

002000 (CR) 

The user has not altered the transfer address. 


HICGRE 

The high core command is used to alter the address of the highest 
virtual memory location that will be transferred during a "dump" 
operation. The default location is printed after the LOAD 
command. The format of this command is: 


HJ CORE 
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The address of the highest virtual memory location to be used 
during a dump operation will be printed. UPD1 will then wait for 
the user to alter or accept the location. The user may enter a 
new location by typing the octal address or accept tre location 
as is by typing a ’’carriage return”. This address must be above 
that of the lowest virtual location (low core) and below that of 
the top of the program buffer. 

Examples: 


. HI CORE 
A 0000 45000 

The user has chanqed the upper virtual location from 40000 to 
45000. 

HI CORE 
100000 (CR) 

The u:pr has allowed the upper location to remain as 100000. 


LOCORE 


The low core command is used to alter the address of the lowest 
virtual memory location that will be transferred in a dump 
operation. The default location is printed after the load 
operation has been completed. The format of this command is: 

LOCORE 


Examples : 

LOCORE 
000200 0 

The user has modified the low memory address to zero. 

LOCORE 

000000 20 

The user has raised the low memory address to 20 (octal). 


DUMP 

The dump command is used to write the program image in the 
program buffer into a tile on a medium. The image size is 
determined by the upper and lower memory limits displayed by the 
HI CORE and LOCORE commands. A transfer address will be put into 
the file. This address can be examined and altered with the XFR 
command. The format of this command is: 
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DUMP [dev: Jo file 


where. 

dev - device to which file is to written; default is system 
device; device is assumed to online and wr i te-enabled 

ofile - file name for image file; wildcards are not accepted; 
file with specified name must not already exist on device 

Examples of the dump command: 

DUMP DYO: ZRLAA1.BIN 

The program image will be written to DYO and given the file name: 

1 7RLAA1 .BIN' 

DUMP MM0.-ZXXAB2 

The program image will be written to MMO and given the name: 

’ 7XXAB2 . There will be no extension since one was not 
spec i f ied. 

DUMP F ILE3.8I C 

The image will be written to the system device and given the 
specified name. 


Sample Modification 


The following sample file modification illustrates the use of the 
preceeding seven commands. It is based on the following patch 
for a fictitious diagnostic named ZXXX80.8IN: 


Location 

Old Contents 

New Contents 

1 224 

106701 

240 

1226 

177660 

240 

1452 

376 

374 


The UPDI-user dialogue used to accomplish this is 
The underlined portion is that typed by UPD1. 
refer to line feed and return. 


shown below. 
(LF) and ( CR) 
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.R UPD1 

CHUP1B0 XXDP+ UPD1 UTILITY 
RESTART ADDRESS: 002432 

♦LOAD ZXXX80.BIN 

XFR: 000001 CORE: 000200, 027230 

♦MOD 1224 


001224 

106701 

240(lT) 

001226 

1 77660 

240 (CR) 

♦MOD 1224 


001224 

000240 

(LF) “ 

001226 

0C0240 

(CR) 

♦MOD 1452 

374 (CR) 

001452 

000376 

♦MOD 1452 


001452 

000374 

(CR) " 


♦DUMP ZXXX81.BIN 


* 

The user examines locatTons previously modified in order to 
verify the changes. The user also renames the file to reflect 
the patch level. 


DEL 

The delete command is used to remove a file, or files, from 
anXXDP+ medium. The actual process f :<r deletion is to remove the 
file name from the directory and deallocate the physical blocks 
used by the file. The format of the command is: 

DEL dev:ifile 

where, 

dev - device where file resides; device is assumed to be 
online and write-enabled; there is no default 

ifile - name of file to be deleted; no default accepted; no 
wildcards allowed 


BOOT 

The bootstrap command is used to start the monitor in the same 
manner as the hardware bootstrap. The purpose of this command is 
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: to allow the user to boot a device other than the original system 

device. The booted device is now the system device. The format 
; of the command is: 

BOOT dev: 

! The device must have a bootable medium mounted. The boot process 

I consists of loading the first physical block (boot block) into 

! the first 256 (decimal) words of memory and starting execution at 

j location 0. 


SEO 0073 
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7 
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7 
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UPD1 Error Messages 


CKERR 

Checksum error occured while loading a tile. 


The output device has no room for the last file specified. 

device error DIRECTORY . . 

The specified device error occured while reading/wri ting to the 
directory. Possible device errors are: READ ERROR (error 

occured while reading a block of data). WRITE ERROR (error 
occured while writing a block of data) and HARD ERROR (error 
occured while accessing the device for a non-transfer operation). 

device error ON INPUT DEVICE . . 

Specified error occurred on the input device specified in the 
last command. 

device error ON OUTPUT DEVICE . . 

Specified error occurred on the output device specified in the 
last command. 


End-of-file indication was detected before expected. 

file already exists . . , . 

The file name specified for output in the last co-nmand is already 
in the directory. Use another name or delete the current file. 

INV ADR 

The address specified in the last MOD command was not a valid 
address in the program buffer. 

INV CMD 

The previous command is rot a recognized UPD1 command. Check the 
appendix for a list of valid commands and reenter the command. 

INV DEV 

User specified an invalid device in the last command. An example 
would attempting to delete a file on the papertape reader. 

INV NAME 

Filename specified in last command was not valid. Check command 
and re-enter. 


INV NUM 

A number specified in the MOD 
NEXFIL 

Specified file name for input 


command was not octal. 

in the previous command does 


not 
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appear in the directory. 

NO DEFAULT , .... 

The previous command does not accept default specifications for 
device and/or file name. Refer to the description of the command 
in question. 

OVERFLOW ... 

The file specified in the previous LOAD command cannot fit in 
free memory space. If you are attempting to patch the file in 
question, use the PATCH utility. 
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This program can be used to modify any binary formatted (.BIN or 
. B I C ) file stored on an XXDP+ storage medium. It is an 
alternative to the LOAD-MOD-DUMP sequence of UPD1 and UPD2. 

There are two specific instances when this program should be 
used. The first is if you are modifying a file which is too 
large to be loaded into the memory space of the system you are 
using. This situation precludes the use of the LOAD-MOD-DUMP 
sequence of the update programs. The second use of this program 
is for the modification of DEC/X11 runtime exercisers. (It is 
assuned that reader is familiar with DEC/X11 usage. If not, 
please read the DEC/X11 User Manual before attempting to use 
PATCH on this software.) As these programs CANNOT be patched 
using the update programs, you must use this program if you wish 
to produce a permanently modified .BIN file for a DEC/X11 RTE. 

******************************** 

Notice 

The DEC/X11 features have 
not been fully implemented in 
DEC/X11 monitor. Please 
patch RTE 's with this 
utility as you would any other 
(non-DEC/xll ) binary file. 
******************************** 


Program Operation 


Operation of this program consists of two phases. The first is 
the building of a table containing the modifications that will be 
made to the file in question. This table is referred to as the 
’‘input table”. The operator fills this table with the addresses 
he wishes to modify within the file, along with the desired 
contents of these addresses. This table may then be saved as a 
file and retrieved for later use. The second phase of operation 
is the combining of the information contained in the input table 
with the actual binary file to produce a new, modified file. The 
original file is not modified by the program. 


Running PATCH 


In order to toad and start *'nis program, you must type the 
following command to the XXD r > monitor; 


! 
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.R PATCH <CR> 

This will cause the PATCH utility to be loaded into and 

begin executing. The program will identify its»fr* with the 
message: 

CHUPA?? XXDP+ PATCH UTILITY 

This will be followed by an operator prompt (*). At this point 
you may begin entering commands to the program. The valid 
commands for PATCH are: 

BOOT Boot specified device 

CLEAR Clear input table 

EXIT Return to XXDP* monitor 

6ETM Load DEC/X11 MAP file 

GETP Load saved input table 

KILL Delete address from input table 

MOD Enter address in input table 

PATCH Create patched file 

SAVP Save input table 

TYPE Print input table on terminal 

In order to patch a file with this program you must perform two 
operations. 

1. You must build an input table containing all of tho 
addresses which you wish to modify within the file, 
along with the contents you want these addresses to 
have. The input table may have a maximum of fifty (50) 
of these entries. 

The commands you may use to build the input tabl are: 

CLEAR 

GETM 

MOD 

TYPE 

KILL 

SAVP 

GETP 

These commands are described below. 

2 . After you have r ompleted the input table you must use 
the PATCH comuand to add the address modifications 
within the input table to the file you want to patch. 
The PATCH command is described below. 

It is important to note that the file you are modifying 
is never completely loaded into memory. 



} 
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Patching Commands 


CLEAR 


Thi command clears the 

i s : 


able of all entries. The command 


mi**. 

is: 


CLEAR*' ro 


* J is usee *hen patching DEC/X11 runtime 

!* will n .e a DEC/X11 'MAP" file of th- 
j; ♦ .v jgw from the specified device and load it intv 
rn Oh: "DEC/X11 MAP FILES"). The ccxwnand format 


GETM Cdev:3filnam.ext<CR> 


The default device is the system device. 


The MOD command is used to enter an address and the desired new 
contents of that address into the input table. The MOD command 
has two modes of operation, depending on whether you are 
modifying a DEC/X1 1 RTE or another type of binary file. These 
two modes are described in the following sections. 


Non-DEC/XI 1 Mode 


When used with binary files other than DEC/X11 RTE's. the format 
of the MOD command is: • 

MOD <addr><CR> 

where <addr> is any valid 16-bit address. Leading zeros may be 
omitted. 

After a carriage return is typed the requested address will be 
retyped, followed by a slash. If this address has not been 

P reviously entered in the input table, the slash will be followed 
y six dashes. (Because the file you wish to modify is not in 
memory, there is no way of know»"r the current contents of the 
t< & ^n you have specified.) the address has been inserted 
input table, the previously entered contents of the 
aa. 1 1 by typed after the slash. 


Page /8 
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Example: 


♦MOD 123456<CR> 
123456/ 


In this example, the operator has specified physical address 
123456 to be modified. The dashes indicate that this is the 
first time this address has been specified. 



♦MOD 1 1040<CR> 
011040/000240 


In this case an actual value appears after the slash. This 
indicates that the operator had previously entered this address 
into the input table and had specified the new contents of the 
address to be 000240. 


At this point you may type the value you wish to have loaded into 
this address. This value can be any octal number from 0 to 
177777. Leading zero's may be omitted. After entering the value, 
you may type either a <CR> or a <LF>. A <CR> will close the 
table entry for this address and cause a prompt to be printed so 
that another command may be typed. A <LF> will close the current 
table entry and make a new entry for the next addressable memory 
location (i.e. <addr>+2). The new contents for this address may 
then be typed. 


Example: 


♦MOD 123456<CR> 

123456/ 000207<CR> 


In the example, the operator has specified that location 123456 
should contain 000207. The carriage return closes the input 
table entry and causes *a prompt (*) to be printed. 

Example: 

♦MOD 1 1040<CR> 

011040/000240 000137<LF> 

011042/ 051502<CR> 

★ 


! In this case the operator has re-opened the table entry for 

| address 11040 and changed the contents to 000137. He/she then 

j typed a <lf> to make a table entry for location 11042. The 

dashes indicate this location had not be*n previously entered 
into the table. This location receives a contents of 51502, then 
! a <CR> is typed to close the table entry and cause a prompt to be 

printed. 


DEC /XII Mode 
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When working with DEC/X11 files, the command has three different 
formats, as follows-^-. - 


MOD <addr><CR> 

MOD MON <modnam> <addrXCR> 

MOD <opmod> <addr XCR> 

Form (1) of the MOD command is the same for DEC/X11 usage as it 
is for non-DEC/Yll usage (see previous section), with the 
exception that 18-bit addresses accepted. 


Forms (2) and (3) of the MOD commend allow the operator 
specifiy locations within aDEC/X"l runtime exerciser (RTE) 
typing the name of a monitor module or option module followed 
an offset into that module. These forms of the command may 
used only if a DEC/X11 ’bap" file has been retrieved by means 
the GETM command (see section: "DEC/X11 MAP FILES ). 


to 

by 

by 

be 

of 


Format (2) is used for modifying locations within monitor 
modules. An example of this format is: 

MOD MCN KTERR 24<CR> . ~ 


The keyword ' MON" ’ is used to indicate that the module is in the 
monitor section of the RTE. In this, case the operator is 
specifying location 24 relative to the beginning of the rnonitor 
module named ’KTERR' 

Format (3) is used for modifying locations within option modules 
of exercisers. <opmod> is tne name of the option module to be 
modified. The name has five characters, the fifth character 
being the copy number (the first copy is 0). An example of this 
format is: 


MOD CPBJ0 100<CR> 

The operator, by typing this command, is indicating that he 
wishes to modify location ICO relative to the beginning of the 
first copy of option module CP8J. 

in all three formats, after the <CR> is typed th° actual physical 
address being referenced will be typed, followed by a slash (/). 
If this address has not been previously entered in the input 

table, the slash will be followed by six dashes ( ). If the 

address has already been entered in the input table, the 
previously entered contents of the address will be printed after 
the slash. 


Example: 


*M0D 012546<CR> 
12546/ 


In the example, the operator has specified physical address 1 2546 
to be modified. The address is retyped, followed by a slash. 
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The dashes indicate that this is the first time this address has 
been specified for modification. 

Example: 

♦MOD MON KTERR 10 <CR> 

007126/000240 

In this case the operator has specified an address within the 
monitor section of the RTE and has done so by using a module 
name. Notice that the program determines the actual physical 
address represented by the command string arguments and prints 
that address. Here an actual value appears after the slash. 
This indicates that the operator had previously entered this 
address into the input table and specified new contents of 
000240. 


At this point you may type the value you wish to have loaded into 
the specified address. This value can be any octal number from 0 
to 177777. Leading zeros may be emitted. After entering the 
value you wish, you may type either a carriage return or a line 
feed. A <CR> will close the current table entry and cause a 
prompt (♦) to be printed so that you can then type another 
command. A <LF> will close the current table entry and make a 
new entry for the next addressable memory word (i.e., <addr>+2>. 
You may then type new conte ts for the address. 


Example: 


♦MOD 012546<CR> 

12546/ 000207<CR> 


In the example, the operator has specified that location 12546 
should contain 000207. The <CR> closes the input table entry and 
causes a prompt to be printed. 

Examole: 

♦MOD MON KTERR 10<CR> 

007126/000240 137<LF> 

007130/ 51502<CR> 


In this case the operator modified the contents of the location 
7126 so it will be 000137 (he had previously specified that this 
address should contain 000240). He then typed a <LF> to close 
the table entry for address 7126 and to create a table entry for 
location 7130. The dashes indicate that this location had not 
been previously entered in the table. This location received a 
contents of 51502 and a <CR> was typed to close the table entry 
and cause of prompt to be typed. 


TYPE 

This command causes the contents of the input table to be listed 
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on the system terminal. The command format is: 

TYPE<CR> 


KILL 

The KILL command is used to delete an entry from the input table. 
The command format is: 

KILL <addr><CR> 


I SAVP 

| This command causes the contents of the input table to be saved 

! as a file with the specified filename on the specified device, 

t The command does not cause any alteration to the input table 

| contents. The command format is: 

T 

| SAVP Cdev: Jf i lnam.ext<CR> 

{ The default device is the system device. 


6ETP 

The GETP command causes the input table to be loaded with the 
contents of a file that was created using the ’’SAVP*' command. 
Execution of this command causes any previous contents of the 
input table to be lost. The command format is: 

GETP Cdev.Of i lnam.ext<CR> 

The default device is the system device. 


Creating the New File 


PATCH 


After the device address modifications have been entered in the 
input table, a new output file containing these modifications can 
be produced with the use of the PATCH command. This command 
reads the specified input file, adds the address modifications 
contained in the input table, and builds a new output file having 
the specified file name. The format of the command is: 

PATCH Cdev:3f i lnam.ext=Cdev:Jf i lnam.ext<CR> 


The default device (input and output) is the system device. The 
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input file and the input table are unaffected by the execution of 
this command. An example command string is: 

PATCH DK1 :SAMPL2.8IN=DK0:SAMPl1 .8IN<CR> 

This will take the file SAMP1.1 .8IN located on device DKO, combine 
it with the address modifications in the input table, and produce 
a new file on device DKl called SAMPL2.8IN. 

After the carriage return is typed, the following instruction 
will be printed: 

IF THIS IS DECX11 TYPE THE MONITOR TYPE. ELSE JUST <CR> 

If you are patching any file which is not a DEC/X11 runtime 
exerciser, then just type a <CR>. If this response is typed, the 
program will commence construction of the output file. When 
execution has been completed the message "DONE will be printed, 
followed by a prompt. 

If you are patching a DEC/X11 runtime exerciser (RTE) you must 
respond to the printed question by telling the program the type 
of monitor contained in the RTE. Note: There are three methods 

for determining the monitor type of the RTE: 

1. Run the DEC/X11 conf igurator/l inker program and type the 
configuration file for this RTE, if it exists. 

2 . Run the DEC/X11 conf igurator/l inker program and type the 
MAP file for this RTE, if it exists. The monitor type will 
be at the top of the listing. 

3. Run the RTE. The monitor type is printed at start-up 
time. 


If the monitor of the RTE is one that does not support memory 
management, the program will now begin building the new output 
file. When this process is complete, the message "DONE” will be 
printed on the terminal, followed by a prompt. If, on the other 
hand, the specified DEC/X11 monitor type is one that does support 
memory management, the program will now check to see if a MAP 
file has been loaded into memory with the GETM command. If there 
is no MAP file in memory, the following instruction will be 
typed: 


TYPE MODQ ADDRESS: 

In order to determine this address, you must look at a listing of 
an appropriate MAP file (see DEC/X11 MAP Files). The symbol MODQ 
is located within the monitor module "CONFIG", so just find the 
module name "CONFIG" on the listing, then look at the symbol 
names underneath the module name until ’MODQ" is found. The 
physical address printed next to the symbol ’MODQ" is the address 
which must be typed in response to the question. If a MAP file 
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was previously loaded into memory using the GETM command, the 
program can automatically find this address and thus will not ask 
the question. 

Next, the following message will be printed: 

IF MODIFYING OPTION MODULES, TYPE LOWEST MODULE 
ADDRESS, ELSE JUST <CR> 

If you are modifying only the monitor section of the runtime 
exerciser, the proper response to this message is to simply type 
a <CR>. If you are patching both the monitor area and one or 
more option modules, or if you are patching only option modules, 
you must now type the address of the first option module that was 
linked into the runtime exerciser. This address may be obtained 
in two ways: 

1. If you have a MAP file listing for the proper monitor type 
(see "DEC/X11 MAP FILES”), find the first occurance of an 
option module name on the listing and use the physical 
address associated with that option module. The option 
modules are located at the end of the listing. The 
physical address of each module is printed next to the 
module name, under the heading 'PH ADDR . 

2. Before running the PATCH program, you can load and run the 
RTE that you intend to patch, then type a ’MAP” command. 
This command causes the starting addresses of all option 
modules to be printeo. for each option module, look for 
the address labelled ’PA:”. Find the physical address 
which is lowest (not necessarily the first one printed!). 

After the typing of a <CR> the program will commence construction 
of the output file. When execution has been completed the 
message 'DONE” will be printed, followed by a prompt. 


E x i 1 1 i ng 


EXIT 

This command returns control to the XXDP+ monitor. The command 
format is: 


EXIT <CR> 


BOOT 

This command boots the specified device. The format is: 

BOOT Cdev: 3<CR> 
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ice is the system device, 
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I XXDP* 
XXDP* 
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DEC /Xll MAP Files 


In order to utilize the full capabilities of the MOD command when 
modifying DE C /XI 1 runtime exercisers, you must have a MAP file. 
The MAP file is produced by the DEC/X11 conf igurator/ l inker . It 
is the symbol table which is generated at link time and saved 
using the SAVM command. (Please refer to the DEC/X11 Use^ 
Manual.) Without the MAP file the MOD command will only accept 
physical addresses as arguments, but if a MAP file has been 
fetched using the GETM command, the MOD command will accept 
module names (both monitor and option module names) as arguments. 

If you are going to modify the option modules of a particular 
runtime exerciser, and if you wish to be able to type the option 
module name and an offset value when using the command, then you 
must use the MAP file generated during the linking of that 
particular RTE . This is because the number and order of the 
option modules in any RTE is unique. If you don't have the 
proper MAP file you will have to manually calculate the physical 
address of the option module’s relative address and type that 
value as the MOD command's argument. 

On the other hand, for any given monitor type (A, B, C, etc.), 
the monitor modules are always linked in the same sequence. This 
implies that if you are modifying the monitor section of an RTE 
and wish to type the monitor module name plus an offset when 
using the MOD command, you need not have the MAP file for the 
particular RTE you are modifying. Any MAP file for the proper 
monitor type will do. For example, if you are modifying the 
monitor area of an RTE of * monitor type C, you may use any MAP 
file which was generated when linking any RTE having monitor type 
C. Similarly, the address of MODQ is also the same for every 
monitor of the same type, so if the PATCH command prompts you for 
the address of MODQ, you may look at any map listing of the 
proper monitor type to obtain the address. 

It is important to remember that when a new release of the 
^EC/XII monitor library is issued, all MAP files generated from 
the previous release of the library become invalid. They may not 
be used when patching files generated with the new library. New 
MAP files must be produced. 

Suggested DEC/X11 Application 


When a DEPO is issued for a DEC/X11 monitor module, the patch 
must be added to every runtime exerciser that is generated 
containing that module (depending on the monitor type). If you 
are in an environment in which you build many RTE's 
(manufacturing, for example), it is suggested that you build and 
save an input table for every monitor type. These saved tables 
can be added to and re-saved every time a new DEPO is issued. 
After any RTE is built with the conf igurator/l inker, simply run 
this program, get the input table for the proper monitor type. 
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add to the table any modifications that must be made to the 
option modules (using tne MAP file if you wish) and then execute 
tne PATCH command. 


Error Messages 


The following is a list of all error messages printed by this 
program: 

? ADDRESS NOT FOUND 

The specified address does not exist as an entry in the 
input table. 

? CHECKSUM ERROR 

A checksun error occurred while attempting to read the 
specified input file. 

? COMMAND NEEDS ARGUMENT 

The command typed by the operator requires an argument, but 
none was given. 

? DELETE OLD FILE 

The specified output filename already exists. 

? device error WILE LOADING DRIVER FOR xx 
? device error WILE READING 
? device error ON INPUT DEVICE 
? device error ON OUTPUT DEVICE 
0 device error DIRECTORY 

The specified device error occured during the operation 
indicated. Possible device errors are: READ ERROR (error 

occurred while reading a block of data), WRITE ERROR (error 
occurred while writing a block of data) and HARD ERROR 
(error occured during a non-transfer operation). 

? END-OF -MEDIUM 

While reading a file, the end of the file was encountered 
before it was expected. 

? FILE NOT FOUND 

The specified input filename does not exist. 

? FILE TOO BiG 
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? INPUT TABLE EMPTY 

The specified command cannot be executed because there are 
no entries in the input table. 

? INPUT TABLE FULL 

The input table is full and cannot accept any more entries. 

? INVALID ADDRESS 

An address given in the last command was not legal 
(possibly an odd number). Check the command and re-enter 
p-operly. 

? INVALID COMMAND 

The last command entered was not a valid command for the 
PATCH Utility. Check the command (especially spelling) and 
re-enter properly. 

? INVALID DEVICE 

The specified command does n^* exist. 

? INVALID FILE NAME 

The specified filename does not have the correct format. 

? INVALID MODULE NAME 

A DEC/X11 module name was incorrectly specified. 

? INVALID NUMBER 

The specified number was not octal. 

? MODULE NAMES NOT ALLOWED WITHOUT MAP FILE 

The operator attempted to specify a module name in the MOD 
command without first loading the proper MAP file. 

? MODULE NAME NOT FOUND 

:;,e spec i f ied module name does not exist within the DEC/XT 1 
runtime exerciser. 

? MUST BE EVEN 

The operator attempted to specify an odd number as an 
address. 

? 
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MUST BE OCTAL 
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The operator attempted to type a non-octal nuwber, 

! 

? HEED NUMBER 

The operator omitted a nuher i c value from a command that 
expected one. 

1 NO DEVICE DEFAULTS 

Default device names are not allowed. 

? NOT ENOUGH ROOM TO LOAD DRIVER 

The driver fcr the specified device will not fit into 
memory. 

? NOT FOUND 

? NUMBER TOO BIG 

The value typed was too large for its intended purpose. 

? OPTION MODULE NAME NOT FOUND 

The specified notion module does not exist. 

? SPEC IF v DEVICE 

There is no default for device in the last command entered. 

Specify the device. 

? SYNTAX ERROR 

The last command was not formatted correctly. Refer to 
detailed descriptions in this chapter. 

? UNEXPECTED END-Of-f HE 

End-of-f ile indication was detected before all expected 
blocks were found. 

? WRONG MAP FILE FOR MONITOR TYPE 

The MAP file in memory does not have the specified monitor 
type. 


SCO 008* 
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Chapter K SETUP 


It is assumed that the reader has read Chapters 8, V and 10 and 
is familiar with the Diagnostic Runtime Services (DRS). 

SETUP is an XXDP+ utility that allows the user to build the 
hardware and software tables for a diagnostic prior to running 
the diagnostic and store the tables with the diagnostic. SETUP 
also combines a special version of DRS with a diagnostic for use 
with ACT and SLIDE. These are DEC manufacturing systems. 

SETUP has the same memory requirements as DRS: 5.75K words. The 

minimum size system that can be used is 16K words. 

To run SETUP, use the XXDP+ run command. The first thing that 
SETUP will do is ask for the *ype of environment you are going to 
be using, XXDP+ or ACT/SLIDE. Below is an example of starting 
SETUP for use in building XXDP+ environment diagnostics. The 
underlined portions are typed by the system. 

.R SETUP 

TAP SET ENVIRONMENT: XX (DP) OR AC (T> ? XX 


SETUP is now ready to accept commands. There are only three 
commands in SETUP: 

SETUP build tables for specified diagnostic 

LIST type a list of DRS diagnostics on a medium 

EXIT return control to XXDP+ 

SETUP 


The SETUP command will cause the specified diagnostic to be 
loaded into memory. SETUP will, then process the table building 
code in the diagnostic. The user will go through the same 
process that would occur if actually running the diagnostic and 
issuing a START command. Section 4 of Chapter 9 describes the 
process in detail. The format of the command is: 

SETUP Cdevo: Jof i te=Cdevi : Jif i le 

where, 

devo - device to which file is to be written; default is 
system device; device must be on-line 

ofile - name of file for the diagnostic that has been SETU D 

devi - device from which file is to be read; default is system 
device; device must be on-line 
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ifile - name of file for the diagnostic that is to be SETUP 

You may give the output file the same name as the input file, but 
you will get a warning message if you do. This is to avoid 
accidental loss of the original file. The message is: 

& 

DELETE ifile? <Y/N/CR=Y) 

If you type a “Y“ or no answer at all, the input file “ifile’ ' 
will be deleted after the SETUP process and the new file will 
then be written. If you specified the ACT environment, the file 
* V»SAC??.SYS“ wilt be appended to the output' file. If you answer 
'V* to the question, SETUP returns to prompt mode so that you may 
enter a new command. 


LIST 

The LIST command is used to obtain a list of all DRS-compatible 
diagnostics on a medium. The format of the command is: 

LIST [dev: Jtf i le.ext J 

where, 

dev - device to search for DRS-compatible files; default is 
the system device 


file. ext - file(s) to search; extension must be 
wildcard specifications are accepted; default 


BIN or BIC; 
is ’ ’* .BI ?’ ' 
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Chapter 15 XTECO 

The XTECO (pronounced ”ex-tee-co") utility is used to create and 
edit (modify) text files. Text files contain ASCII data 
representing valid text. Valid text consists of all printing 
characters, tab, carriage return, line feed and form feed. The 
prime text files in XXDP+ are batch control (chain) files. This 
utility, which is a simple editor, is a l.mited subset of TECO, a 
character editor supported by most of DE('s operating systems. 
The commands are few and simple, but adequate for the task. 

Before describing the commands in detail, let's look at some 
basic XTECO concepts. To XTECO, a text file contains one long 
string of characters sort of like beads on a string. ft 
processes the file one character at a time. The utility can only 
nave a certain number characters in memory, so only a segment of 
the string can be worked with any given time. There are special 
characters (carriage return and line feed) that act as signals to 
XTECO to tell it when one line of text ends and another begins. 
This allows the editor to manipulate lines of text as well as 
characters. The editor keeps track of where it is on the string 
with a pointer. This pointer is manipulated by the various 
commands and is used by XTECO to locate where new text is to be 
placed and old text removed or modified. This pointer ma> be 
moved back and forth over the portion of the string in memory at 
the time, but cannot go backwards into the portion of the string 
already processed and placed into the new file. Thus the user 
should understand two basic concepts: text as a string of 

characters and a pointer to locate the editor on that string. 

| As previously mentioned, only a certain segment of a text file 

* may reside in memory at any given time. XTECO processes files by 

reading a segment from the input file into memory, doing any edit 

| functions on that segment (as directed by the user! and then 

writing the segment into the output file. This process continues 
until the entire input file has been acted upon. In the case of 
the "TECO*’ conwand (see next section) where the input and output 
file may have the same name and reside on the same medium, XTECO 
creates a temporary output file which replaces the input file 
after the edit process is complete. 

Starting the Edit Process 


The first thing a user must do after starting XTECO is to 
initiate the process of editing text. (XTECO is started by 
tyoinq 'ft XTECO ' in response to the XXDP+ monitor prompt.) There 
are three commands to do this. 




TEXT - used to create a new file 

TECO - used to modify a file 

EDIT - used to modify a file 
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Each of these commands puts XTFCO into what is called "edit 
mode*'. While in this mode, text information can be created, 
deleted or modified. There is one difference between the EDIT 
and TECO commands. The TECO command may be used with 
random-access devices ( i . e . , disks) only and the input file name 
is all that is required. The output file name will be the same 
as that of the input file. An output file is created during the 
edit process and is used to replace the input file after 
completion of the edit process. The EDIT command can be used 
with any type of device, but the input and output devices must be 
different (either different device types or different units of 
the same type). The formats of these commands are: 

TEXT Cdevo.Oofile 
TECO Cdevi :3if i le 
EDIT Cdevo:3of i te=tdevi :3if i le 


where, 

devo - output device where the new file is to be stored 
ofile - name of file for output 
devi - input device from which old file is to read 
ifile - name of input file 

After one of these three commands has been executed, XTECO will 
be in "edit mode" and will now issue double quotation mark ("") 
for a command prompt instead of an asterisk. There are thirteen 
commands that are used in edit mode. These are listed by type of 
function in the following table. 
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Edit Mode Commands 


Pointer Location 


l - move the pointer line by line 
C - move the pointer character by character 
J - move the pointer to the beginning of text 
Z J - move the pointer to the end of text 

Search 


S - search for specified string in text now in memory 
N - search for specified string in remainder of text file 

Modify/Display Text 


T - type text 
D - delete character(s) 

K - delete line(s) 

I - insert text 

A - append text to that currently in memory 
Terminating Edit Mode 


EX - exit edit mode 


All commands are terminated by two "altmode" or "escape*' 
characters. The altmode or escape key is usually the 
left-uppermost key on DEC terminals. The character is echoed on 
the terminal as and is shown as such in examples in this 
chapter. 

The following sections explain each edit mode command in detail. 
Following these explanations, there is a sample edit session. In 
examples where it is important to display tne position of the 
pointer, a caret, " A * , is used to designate the position within 
the sample text. This is for illustrative purposes only! This 
character is not used for this purpose in actual operation. 


Pointer Location 


L Command 


The L command is used to move the pointer on a line-by-line 
basis. A line of text is a string of characters between carriage 
return/line feed sequences. (This sequence is produced by typing 
the "return" key on your terminal.) The pointer may be moved 
either backward or forward any number of lines in the text 
currently stored in memory. The pointer is always positioned at 
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the beginning of a line after execution of the L command. The 
format of the command is: 


Cn3L$$ 

where n is an optional argument that specifies the direction to 
move and the number of linos encompassed by the move. It is a 
decimal number tnat is positive for forward motion and negative 
for backward motion. If it is not specified, *V is assumed. 
(The command is terminated by two altmode or escape characters 
which are echoed on the terminal by “SS" as shown above.) 

Following are examples of the L command. In these examples, a 
caret, indicates the position of the pointer after execution 
of each command. XTECU's prompt ("") is also shown in the 
examples. 

Command 


* 1SS 


I 

1 "-1L$S 


*2L$$ 


C Command 


The C cevnmand is used to move the pointer on a 
character-by-character basis. Lines are not recognized by this 
command; tne carriage return/line feed seguence is treated as 
two characters. The pointer may be moved forward or backward any 
number of characters within the text currently stored in memory. 
The format of the command is: 

CnJCSS 

where n is an optional argument that specifies the direction to 
move and th<? number of characters encompassed by the move. It is 
a decimal number that is positive for forward motion and negative 


Text in Memory 

R ZRLA A ?? 

IF ERROR THEN 

PRINT RL01 HAS HARDWARE PROBLEM 
END 

R ZRLA?? 

A IF ERROR THEN 

PRINT RL01 HAS HARDWARE PROBLEM 
END 

A R ZRLA?? 

IF ERROR THEN 

PRINT RL01 HAS HARDWARE PROBLEM 
END 

R ZRLA?? 

IF ERROR THEN 

A PRINT RL01 HAS HARDWARE PROBLEM 
END 


Page 
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for backward motion. If it is not specified, “1" is assumed. 
(The command is terminated by two altmodes or escapes which are 
echoed on the terminal as "Si" as shown above.) 

Following are examples or the C command. The caret, " A, ‘ 
indicates the position of the pointer after execution of each 
command. XTECO's prompt is also shown in the examples. 

Command Text in Memory 

;NEXT COMMAND WILL T A EST RP06 
; ALL ERRORS WILL BE REPORTED 

**CSS ;NEXT COMMAND WILL TE A ST RP06 

; ALL ERRORS WIL BE REPORTED 

’ -3CS$ .NEXT COMMAND WILL A TEST RP06 

;ALL ERRORS WILL BE REPORTED 

•*10CS$ ;NEXT COMMAND WILL TEST RP06 A 

; ALL ERRORS WILL BE REPORTED 

' 3C$$ ;NEXT COMMAND WILL TEST RP06 

; A ALL ERRORS WILL BE REPORTED 

Please note the effect of the carriage return/line feed sequence 
on the execution of the last command in the example above. The 
sequence counts as TWO characters. 


J Command 


The J command is used to position the pointer at the beginning of 
all text currently stored in memory. The format of the command 

is: 

J$% 

The command is terminated by two altmodes or escapes which are 
echoed on the terminal as "$S” as shown above. Following is an 
example of the J command. The caret, “ A ". indicates the position 
of the pointer before and after command execution. 

Initial state: 

R PROG1 
R PROG? 

R PR0G A 3 

After execution of the J command: 

A R PR0G1 
R PROG? 

R PROG 3 
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Z J Command 

mm, mm mm 'mm mm mm mm mm **- mm 

the Z J command is used to position the pointer after all text 
currently in memory. The format of the command is: 

ZJll 

The command is terminated by two altmodes or escapes which are 
echoed on the terminal as ’IS" as shown above. Following is an 
example of the ZJ command. The caret. indicates the 

position of the pointer before and after command execution. 

Initial state: 

*R PR0G1 
R PROG? 

R PR0G3 

After execution of the ZJ command: 

R PR0G1 

R PROG? 

R PROG 3 
* 


Search 


S C omrnand 


The S command causes the editor to search for a specified string 
of characters in the text currently stored in memory. Searches 
take place in the forward direction only. The search encompasses 
the text in memory only. The format of the command is: 

SstringSS 

where "string" is the character sequence to search for. This 
string may consist of any nunber of valid characters, including 
tab, carriage return and line feed. The command is terminated by 
two altmodes or escapes which are echoed on the terminal as "IS 
as shown above. 

The editor will search through text in memory, starting from the 
current pointer position, until either a match is found or the 
end of text is encountered. An error message is printed if a 

match is not found. The pointer is positioned AFTER the string 

fotjnd by the search or after alt text in memory if no match is 

made. (The user may reposition the pointer to the beginning of 

text in memory after a fai led search by using the J command. ) 


Following are examples of the S command. The caret. 


t * 
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indicates the post ion of the pointer after execution of each 
command. XTECQ's prompt <””> is also shown in the examples. 

Command Text in Memory 

*p I ipnp 

PiP DX0:=DX2: *.BIN 
EXIT 

“SDxm R UPD2 

PIP DXO: =DX2 : * .BIN 
EXIT* 

“JS$ a R UPD2 

PIP DX0:=DX2:*.8IN 
EXIT 

’ *SDX2$S R UPD2 

PIP DXO: =DX2* : * .BIN 
EXIT 

In the above example, the first search failed. The editor would 
print an error message: 


'NOT FOUND: DXl 


N Command 


The N command has the effect of a ' bon-stop” S command. It is 
exactly like the S command, except that it will search through 
all remaining text in a file. If the editor fails to find a 
match for the specified string within the text currently in 
memory, it will write the text in memory into the output file and 
bring more text in from the input file. This process continues 
until either a match is found or the entire input file has been 
checked. The J command may not be used to recover from a failed 
search if that search caused the section of text that you started 
from to be written to the output file. In this case, the user 
must exit edit mode and re-enter with the previous output file as 
input. 


Modify/Display Text 


T Command 

The T command is used to type text on the console terminal . The 
text typed is relative to the position of the pointer in the text 
currently storer ’n memory. Typing is line-by-line and any 
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nutiber of lines before or after the current pointer position may 
be typed. A line of text is a string of characters between 
carriage return/line feed sequences. (This seguence is produced 
by typing the "return" key on your terminal.) If the pointer is 
positioned within a line of text, typing will start/conc lude at 
the pointer position (see examples). The format of the command 
is: 


CnJTII 


where n is an optional argument that specifies the number of 
lines to be typed and whether the lines preceed or follow the 
current pointer position. It is a decimal nunber that is 
positive 'f the lines follow the pointer and negative if the 
preceed it. If n is not specified, "1 * is assumed. The command 
is terminated by two altmodes or escapes which are echoed on the 
terminal as "IS" as shown above. 


There is also a special form of the T command which will cause 
all text currently stored in memory to be typed, regardless of 
the position of the pointer. This command is: 'HT'\ 

Following are examples of the T command. The caret, in the 
sample text indicates the position of the pointer. XTECO's 
prompt ('"') is also shown in the examples. 


first sample text: 

.BATCH CONTROL FILE FOR TESTING THE DZ11 
A R ZDZA?? 

R ZDZ8?? 

.END OF DZT1 TESTING 

Command Text Typed 
"Til R ZDZA?? 

"-1TSI .-BATCH CONTROL FILE FOR TESTING THE DZ11 

*?TI$ R ZDZA?? 

R ZDZB?? 

Second sample text: 

R PROG1 
R PRO*G? 

R RR0G3 


Command 

"T|| 

"*1T$$ 

*X)TI$ 

•ViTIS 


Text Typed 

G? 

R PROG! 

R PRO 

R PRO 
R PR0G1 
R PROG? 

R PR0G3 
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D Command 


The D command is used to delete characters from the text in 
memory. Any number of characters, either preceed inq or following 
the current pointer position, may be deleted. The format of the 
command is: 


CnJDSS 

where n is an optional argument that specifies tne number of 
characters to be deleted and whether the characters preceed or 
follow the current pointer position. It is a decimal number that 
is positive if the characters follow the current pointer position 
and is negative if they preceed it. If it is not specified. ’*1" 
is assumed. The command is terminated by two altmodes or escapes 
which are echoed on the terminal as ‘%S‘ as shown above. 

Following are examples of the 0 command. The caret. ”**', 
indicates the position of the pointer. XTECO’s prompt (*'**> is 
also shown in the examples. 

Command Text in Memory 

.COMMENT LINE IN BATCH CONTROL FILE 

' %DU ; COM* LINE IN BATCH CONTROL FILE 

‘ V3DSS ;* LINE IN BATCH CONTROL FILE 

'DM . ‘LINE IN BATCH CONTROL f II f 


K Command 


The K command *s used to delete lines cf text from the text 
stored in memory. A line of text is a string of characters 
between carriage return/ l ine feed sequences. (This sequence is 
produced by typing the ’ ‘return* * key on your terminal.) Deletion 
of a line includes the deletion of the terminating carriage 
return/line feed sequence in addition to the characters in the 
line. Any number of lines may be deleted either preceeding or 
following the cu« rent position of the pointer. If the pointer is 
positioned within a line, not all of the line will be deleted 
(see examples that follow). The format of the command is: 

CnJKSS 

where n is an optional argument that specifies the number of 
lines to be deleted and whether they proceed or follow the 
current pointer position. It is decimal number and is positive 
if the lines preceed the pointer and negative if the follow it. 
If this argument is not specified. *T‘ is assumed. The command 
is terminated by two altmodes or escapes which are echoed on the 
terminal as 'll is shown above. 
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Following are examples of the A command. The caret. 
indicates the position of the pointer after the execution of each 
command. XTECO*s prompt (*”*) i:, also shown in the examples. 

Command Text in Memory 

.START OF CONTROL FILE 
*R PROG1 
R PROG2 
R «K)G5 
R PR0G4 
.END Of FILE 

'*** .START Of CONTROL FILE 

*R ^ROG2 
R PROG S 
R PROG4 
.END Of FILE 

*MA*t *R PROG2 

R PROGS 
R PROGA 
.END Of FILE 

‘?KSI *R PROG** 

END Of F ILE 

"SCW R P*ROGA 

.END Of FILE 

’%» R P-.END Of FILE 

Note the effect of the A command when the pointer is not 
positioned at the beginning of a line. Vou can easily determine 
the effect of any A co m m a nd by issuing a T c o mm and with the 
identical format. whatever is typed after you issue the t 

f ommand is what will be deleted by tne A command. <fhe commands 
T and 5 a are of identical format . ) 


I Command 

The f command is used to insert *ew text. f he text if inserted 
after the current pointer position. The pointe wfU fee 

f ositioned after the new text upon completion of the insertion, 
he format of the command is: 

Ite«tU 

where "’text” is the text to be inserted. This text mv consist 
of any valid text characters. Valid text characters are at l 
printing characters, tab* carriage return. Hne feed and »©rm 
feed, 'he c o m man d is terminated by two aitmodes ©r escapes which 
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are echoed on the terminal as "SS" as shown above. 

Following are examples of the 1 command. The caret, 
indicates the position of the pointer after execution of each 
command. For purposes of illustration, line terminators are 
depicted in these examples. The return typed by the user is 
represented as "<RET>"". The two character sequence generated by 
the return and stored in the text is represented as "<CR><LF>* . 
XTECO's prompt ("") is also shown in the examples. 

Text in Memory 

R UPD2<CR><LF> ' 

R UPD2<CR><LF> 

PIP* 

R UP02<CRXLF> 

PIP DK0:=DK1:<CRXLF> 

A 


FILE DK1:=DK*:<CRXLF> 
FILE OKI :=DK2 a :<CRXLF> 


A Command 


The A command is used to increase the amount of text stored in 
memory. This is done by reading the next section of text from 
the input file and "appending” it to the text already in core. 
You may append as many sections of text as memory size limits 
allow. The format of the command is: 

ASS 

The combined sections of text in memory are treated as a single 
section by the previously described commands. 


Command 

"IPIPSS 

"I DK0:-DKl :<RET> 

ss 

"I2SS 
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Terminating Edit Mode 


EX Command 


The EX commano is used when all editting operations have been 
completed. The output tile is closed. If the edit session was 
initiated using the TECO command, the input file is renamed with 
a .8AK extension and the output file will be given the original 
name of the input file. XTECO will no longer be in edit mode as 
signified by the switching of the prompt character back to an 
asterisk <"* ) from a double quote (• V). The format of the 
command is: 

EXU 


* m m m v m - m t . 

Combining Edit Commands 


The user can combine several edit mode commands on a single 
command line. This is done by separating each command by a 
single escape (altmode) character and then terminating the entire 
string of commands by two escapes, for example, the following 
commands: 

m 

*T>m 

•ns* 

m. 

can be combined into a single string: 

•NTESTSOTSTSS 

In both cases. XTfCO will do a non-stop search for the string 
•TEST", type the characters from the beginning of th# line whe^e 
the string was found to the current pointer position and then 
type the characters from the current pointer position to the end 
of the line. Combining commands is merely a convenience for the 
user. It is suggested that the user not attempt to combine 
commands until he or she is familiar with the operation ©f 
individual commands. The next section has sample edit sessions 
that show both methods. 


m m a**fc«Nn s*** 

Sample XTECO Edit Session 

■m. m am 4a m m m as nh «a>ew m> m> m m mmmmmmm 


yhat follows is a series of sample edit sessions that wMi show 
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tha usar tha various ways o* handling XTECO. In thasa a*a«plas. 
tha undart inad taut is that which is typad by XTfCO. At 
afipropr iat* locations, conwants hava baan inctudad for raadar 
assistanca. Thasa comments ara enclosed in square brackets <U> 
and should not be c on f us ad with tha actual dialogue that is 
taking place batwaan usar and software. 

Staple Mat hod for Creating a Text f la 


.R XTECO 
•TEXT T 6 ST.CCC 

Cusar craat r g new fila r-n 

system device callad TEST.CCO 

'* * i ; this is a batch consol job tor testing tmi rxO’ 

.THIS IS A f ICTIONAl JOB TOP DEMO Of XTECO ONL V ? 

A ZRXX?? 

RE S/PAS : 1 

N 

EXIT 

; T Mf HAST RXQ1 DIAGNOSTIC HAS BEEN Rt*. 

a 

RE S/PAS ;1/TE$: .1-5 

N 

pxr 

;ENP Of RxOI TEST 

Si 

!XSS 

•EXIT 


Changing an Existing Text fila 


.« XTECO 
•TOO TEST.CCC 

CTha usar is doing to changa TEST.CCC* 
on tha system device. J 

' *SRX02$$ 

? NOT POUND: RX02 

**JSS 

•‘Tit 

; THIS IS A BATCH CONTROt JOB fUR TESTING THE RX0t 

f lS» 

"bt% 

.-THIS IS A f ICTtONAl JOB fOR OEMO Of XTECO ONI IT? 

f U%% “ . 

•EXIT 


«*■«►■«» «* ■«*■** urn 



B 




sec oios 
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XXD P * utility Program* — xTECO 


Non-edit Commends 


There are three XTECO commends that are not related to actual 
tent tile editting. These commands are provided for user 
convienience. 

TYPE and PRINT 

The TYPE and PRINT commands are used to print text files on the 
console terminal and line printer respectively. They are 
equivalent to the UPD<? commands of the same name. 

EXIT 

The EXIT comm, and is used to return control to the xxDP* monitor. 
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PART V — XXDP+ Device Drivers 


Chapter 16 


Devices Supported 


XXDP+ supports most mass storage devices. In addition it 
supports some non-f i le-structured devices such as paper tape. 
The following table lists all devices supported, _ the mnemonic 
used to specify the device and the name of the monitor and driver 
files. The "??" characters in the file name refer to the 
revision and patch level which may vary over time. 




Device 

Mnemonic 

Monitor 

Dr i ver 

TU60 

CT 

HMCT?? 

hdct?? 

RP04/S/6 

DB 

HMD8?? 

HDDB?? 

TU58 

DD 

HMDD?? 

HDDD?? 

RK05 

DK 

HMDK?? 

HDDK?? 

RL01/2 

DL 

HMDL ?? 

HDDL?? 

RK.06/7 

DM 

HMDM? ? 

HDDM?? 

RP02/3 

DP 

HMDP?? 

HDDP?? 

RM02/3 

DR 

HMDR?? 

HDDR?? 

RS03/4 

DS 

HMDS?? 

HDDS?? 

DEC TAPE 

DT 

HMDT?? 

HDDT?? 

RX01 

DX 

HMDX?? 

HDDX?? 

RX02 

DY 

HMDY?? 

HDDY?? 

LOW SPD PT 

KB 

- — 

HDK8?? 

PRINTER 

LP 

— 

HDLP?? 

TM02 

MM 

HMMM?? 

HDMM?? 

TS04 

MS 

HMMS?? 

HDMS?? 

TEH) 

MT 

HMMT?? 

HDMT?? 

PDT11 

PD 

HMPD?? 

HDPD?? 

HI SPD PT RD 

PP 

— 

HDPP?? 

LOW SPD PT 

PT 

— 

HDPT?? 

HI SPD PT RD 

PR 

— - 

HDPR?? 


All drivers assume that the CSR address for the device is the 
standard address as given in the Peripheral Handbook. If you 
have a system with a device at a non-standard address, you can 
modify location 24 in the driver using UPD2 or UPD1 . (The CSR 
address is stored in location 20 of the monitor.) 
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Chapter 17 Driver Error Messages 


XXDP+ device drivers are, by necessity, small and limited in 
function. They can detect and report three types of errors: 
read, write and hard. These errors are reported and control is 
returned to the utility being used. The utility then takes any 
further action required. Since the functionality of the drivers 
is limited, the user is required to run diagnostics on the device 
in question if an error persists. 


I 


| 


I 
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SEQ 0109 




Chapter 18 Monitor and Required Files 


The minimum files that must be put on a bootable XXDP+ medium are 
the monitor for that medium, the device driver for that medium, 
the DNS (file name: HSAA??.SY$) and the directory utility (file 

name: HUDI??.SYS). The monitor file (see Chapter 16 for names) 

must be loaded by UPD2 and then saved on the medium using either 
the SAVM or SAVE commands. These commands are described in 
Chapter 11. The SAVM command is used for random access 
(disk-type) devices. The SAVE command is used for sequential 
access (tape-type) devices. The remaining files may be put onto 
the medium using any UPD2 file transfer commands. 

Examples (RX01 and TE10): 

.R UPD2 

♦LOAD HMDX?? . SYS “ 

♦SAVM DXO: 

♦FILE DX0:=HDDX??.SY$ 

♦FILE DX0:=HUDI??.SYS 
♦FILE DX0:=HSAA??.SYS 
♦EXIT 

.R UPD2 

♦LOAD HMMT??.SYS 
♦SAVE MT0:HMMT.SAV 
♦PIP MT0:=HDMT??.SYS 
♦PIP MT0:=HUDI??.SYS 
♦PIP MT0:=HSAA??.SYS 
♦EXIT 

The process described above places the MINIMUM XXDP+ system on a 
medium. You may add as many other system components (drivers and 
utilities) as you wish. Don't forget to modify location 1000 in 
the monitor if you will be using a system that is on 50Hz power. 
(Location 1000 must contain a 0 for 60Hz and a 1 for 50Hz.) The 
next chapter describes a batch control file that builds media 
i automatically. 
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Chapter 19 


Update Kits 


There is a batch control file that will update/build XXDP+ media 
automatically. The file is called XX81D.CCC. To start the file, 
use the chain command. The file accepts switches that specify 
the media type to build and the mode in which to build. All 
supported XXDP* media may be built. The media being built are 
always assummed to be mounted in drive (unit) 0 of the device and 
that the drive is ready and write-enabled. The format of the 
command line for starting the build process is: 

C XXBLD/deviceC/modeJ 


where, 

device - the mnemonic for the device to be bui It /updated.-*' 
Supported devices and their mnemonics are listed in chapter 
16. If no device is specified, a short help message will 
be printed. 

mode - manner in which to build/update. Available modes are: 

DRIVER a bootable medium with all XXDP+ drivers 

MONITOR a bootable medium with all XXDP+ monitors 

UTILITY a bootable medium with all XXDP+ utilities 

SYSTEM a combination of the above three modes 

If no mode is specified, a bootable medium is built. A 
bootable medium consists of a bootable monitor image, the 
runtime services, the directory utility, the driver tor the 
medium and UPD2. 


Except in the case of sequential devices (e.g.; magtape), the 
medium is not changed except for the replacement /add it ion of the 
new XXDP+ components specified by the mode switch. You may want 
to back up files that are critical however. Sequential media are 
destroyed. There is a warning message given and the user is 
given the opportunity to abort the process. 

To obtain help while running the update batch job, use the 
following command: 


C XX8LD/HELP 
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PART VII — Batch Control (Chaining) 


Chapter 20 


Introduction to Batch Control 


XXDP+ has a facility for running programs without operator 
intervention called batch control or chaining. The commands that 
would normally be issued by an operator are put into a text file 
(using XTECO - Chapter 15) and the monitor processes the commands 
in this file rather than requiring an operator to enter each 
command manually. Once a batch control file has been created, it 
can be used over and over again. The batch control process 
releases the operator from having to do repetitive tasks such as 
building new media or running a common set of diagnostics. More 
importantly, batch control allows a user to develop a test 
strategy and use the strategy consistently. This is done by 
selecting the proper diagnostics and running them in a particular 
order ana mode to achieve the best test process. Onct the 
process is developed, it is put into a batch control file. 

Older versions of XXDP and XXDP+ had very limited batch control 
services. Essentially the user could 'chain" together a series 
of run commands which would run various diagnostic programs, such 
as : 


R PROG1 
R PROG2 
R PR0G3 

The user could intermix comments that would be printed as the 
chain was processed. This primitive process was adequate for 
most simple procedures, but was not adequate for more 
sophisticated operations such as the update kits described in 
Chapter 19. 

XXDP+ now contains a fairly sophisticated set of batch control 
functions listed below. These are described in this chapter. 
Techniques for using these functions *o run diagnostics and 
utilities are described in subsequent chapters. 


Batch Control Functions 


Monitor Commands 
Utility Commands 
DRS Commands 


monitor commands: R, L, S, C, and E) 

UPD2, SETUP, etc. 

all DRS commands and diagnostic dialogue 
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conditionals 


GOTO tag 


QUIET 


PRINT 

SMI/CMI 


QUIT 

WAIT 


Monitor Commands 


Certain of the monitor commands described in Chapter 6 can be 
used in a batch control file. They are the R, L, S, C and E 
commands. There are two functions which are different when used 
under batch control instead of operator control. First, the R 
(Run) Command has a pass switch for use with diagnostic programs 
which are not DRS compatible. The diagnostic may be run a 
certain number of passes by using the switch as shown: 

R D I AG/5 

DIAG will run 5 passes before the batch operation continues on. 

The C (Chain Command) may be used in a batch file with one 
restriction. Batch operations can be nested one level only. 
That is, a batch file may start another batch file and then 
continue after the second file has been processed, but the second 
batch file may not start another (third) file. 

With these exceptions, the monitor commands function under batch 
control as they would under operator control. 


Utility Commands 


The commands for various XXDP+ utilities may be used in batch 
control operations. Chapter 22 details this function. 





sections of the batch file can be 
processed conditionally under operator 
control or runtime conditions 

begin processing at another section of the 
batch file designated by "tag*’ 

inhibit printing of batch file if printing 
or enable printing if printing was 
inhibited previously 

temporary override of QUIET 

enable/disable manual intervention 
operations in specialized diagnostics 

terminate the batch operation 

stop batch operation until the operator 
types a Control X 


DRS Commands 
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All of the DRS commands described in Chapter 9, including all 
switches and flags, can be used in a batch control file. All 
dialogue that would normally take place between an operator and a 
DRS diagnostic can also be placed in a batch control file. 
Chapter 21 describes this function. 


Conditionals 


Sections of a batch control file can be processed, or not 
processed, based on either operator input or certain conditions. 
There are three conditional statements. 

1. IF condition THEN 
statement (s) 

END 

2. IFERR THEN 
statement (s) 

END 

3. IFLMD n THEN 
statement (s) 

END 

If the condition specified is true, the statements between the 
THEN and END statements will be processed. If the condition is 
false, these statements will be ignored. 

The conditions used in the first type of statement are ASCII 

character strings which are defined by the person writing the 

batch file and used as switches by the operator. For example, 

suppose a person is writing a batch file for running UPD2 and 

doing some file operations. If a part of the process requires 
the presence of an RX02 on the system, there would be a need for 
the operator using the batch file to be able to specify whether 
or not there was an RX02 present. The batch file writer would 
define a conditional section of the file as shown below. 

IF RX02 THEN 
statement(s) 

END 

The condition 'ftXO 2” is now used by the operator as a switch to 
the Chain command: 

C FILE/RX02 

The monitor stores the string of characters for comparison with 
the conditions in the batch file. There is only one ore-defined 
switch and the writer is free to create any other ne or she 
desires. The pre-defined switch is *'/QV * (quick verify) which 
causes diagnostics to be run one pass only. Any number of 
switches may be used in a command. 
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The second type of conditional statement can be used with 
DRS-type diagnostics only. If a test error was detected by the 
last DRS-type diagnostic that was run in the batch file, the 
statements will be processed. 

The third type of conditional uses the media-type byte in 
physical location 41. If the type code matches the one specified 
in the conditional (“h"), the statements will be processed. 


WTO 

The GOTO statement is used to transfer control within a batch 
control file. When the monitor encounters a GOTO statement, it 
searches for the specified tag and resumes the batch process at 
the statement following the tag. A tag is an alphanumeric string 
terminated by a colon The tag may occur before or after 

the GOTO statement in the batch file. The following are examples 
of the GOTO steatement : 

TAG1 : 

R PR0G1 
GOTO TAG1 


GOTO TAG? 


TAG?: 

R PROG5 

In the first example, the batch process will loop backwards until 
interrupted by the operator. In the second example, control will 
be transferred forward to TAG?. Any statements between the GOTO 
statement and the tag are ignored. 


QUIET 

•nt 

The QUIET statement is used to control typing of the batch file. 
The statement is used like a ’"’f l ip-flop . The first time the 
statement is encountered, all typing is suppressed (with the 
exception of error messages) . The next time it is encountered, 
typing is reenabled. The third time it is encountered, typing is 
inhibited again and so on. 


PRINT 


The PRINT statement is used to force the typing of a line of text 
white typing is inhibited by the QUIET statement. The format of 
the statement is: 
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PRINT text 

The text on the same line as the PRINT will be typed. 


SMI/CMI 


The SMI and CMI statements are used to enable and disable manual 
intervention modes in ORS-type diagnostics. Normally all testing 
that requires manual intervention by an operator are inhibited 
during batch control operations. These statements allow this to 
be ocer-ridden. Obviously caution is suggested when using this 
feature. 

SMI - set 'allow) manual ir ter vent ion 

CMI - clear (don't allow) manual intervention 

CMI is the defaul' state when a batch job is started. 


QUIT 

The batch job is immediately stopped when a QUIT statement is 
encountered. The monitor returns to normal operator mode. 


WAIT 

When a WAIT statement is encountered, the monitor stops 
processing the batch file and waits for the operator to type a 
CTRl-X (typed by depressing the CTRL and X keys together * This 
is typically used m conjunction with manual intervention feature 
as shown in the example below. 

PRINT THE NEXT DIAGNOSTIC REQUIRES THAT A 
PRINT SCRATCH MEDIUM BE MOUNTED IN THE RlOI/OZ. 

PRINT TYPE *X WHEN READY 
(AIT 

R ZRLA?? 


Comments 

Comments may be placed in the batch file. These will be typed as 
the tile is processed unless QUIET mode has been invoked* 
Comments are strings of text that start with a semicolon. 

.THE NEXT PROGRAM TESTS Tnf D/M 

k /D/6 ’ ? ;RUN fHf DIAGNOSTIC 
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Batch Control of Diagnostics 


for the purposes of batch control, there are two types of 
diagnostics: cbainabie non- DBS-type diagnostics and OwS-type 

diagnostics. The first type can be batched by a simple nas 

C " ' * 

TyaWXfsSP wWI * 

» DIAGC/nJ 

where n is an optional, argument that specifies the nabtr of 
passes that the diagnostic will run. The default is one pass. 

S-type diagnostics require complete batch control. AM 
saands normal iy entered by an operator must be in the batch 
i le. for example: 

W DIAG2 
Siam /pass: f 

Y £ answer for (MANGf MM.) 

1 i answer for ouatoer 0 f units) 

(insert 'answers for all 'MW questions} 
f X! T Cto return control to batch Job) 

Thn is just a short example. The concept to note is *hat the 
batch file is an IH0JWC? CQPtttND file for D*$. Alt commends 
that are required when 'running under 1 operator control are 
necessary in the file. If the diagnostic program in the above 
example had used a software table, it would have been necessary 
to provide the commends required to seaport it. 

the user does not have to enter 1 aM c o m mand * via the batch file 
however. By using the S€ TUP utility < Chapter Hi, aM hardware 
and software information could toe supplied to the diagnostic 
prior to running the batch job. This i* the recommended awthod 
for 1 using WtVtype diagnostics <n the batch control am»ir umwM 
If you preset all the parameters, the fol lowing commends are all 
that are necessary: 

a DJAW 
5 tAft t /PA r*.*n 

N 

fi|T 


where n is the rsmtoer of passes to execute. 




N 9 

XXDP+ System User’s Manual 117 

Batch Control 


SEQ 0117 


Chapter 22 


Batch Control of Utilities 


Most of the XxDPr utilities may be used under batch control. The 
utilities which are batch controlable are: UPD2, SETUP, and 
PATCH. To run a utility under batch control, simply create a 
batch file that contains all of the commands that would normally 
be entered by an operator. For example, to build an RX01 floppy 
diskette for XXDP+ using UPD2 under batch control: 

R UPD2 

LOAD HMDX??.SVS 
SAVM DXO: 

FILE DXO:=HSAA??.SYS 
FILE DX0:-HUDI ?? . SYS 
FILE 0X0:=HDDX?? . SYS 
EXIT 

Note that the dialogue with UPD2 must end with an EXIT command in 
order to finish the batch job or to allow further batch 
functions 
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Appendix A XXDP+ Secondary Bootstraps 


To be supplied in future revisions. 


Appendix B Bootstraps 


To be supplied in future revisions. 
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execute only the tests specified 
execute ddddd passes (ddddd = 1 to 64000) 
set specified flags 

report end-of-pass after each ddddd passes 
(ddddd = 1 to 64000) 

command will affect only specified units 


DPS Flags 


Flag 


HOE 

LOE 
IER 
I BE 


IXE 

PR I 
PNT 
BOE 
UAM 
I SR 


I DR 
ADR 
LOT 
EVL 


UPD1 Command*' 


CLR clear UPD1 program buffer 

LOAD load a program 

MOD modify file image in memory 

XFR set transfer address 

HI CORE set upper memory limit for dump 

LOCORE set lower memory limit for dump 

DUMP dump a program image 

DEL delete a file 

BOOT bootstrap a device 


F f feet 


holt on error - control is returned to runtime 

services :ommand mode 

loop on error 

inhibit ill error reports 

inhibit . I l error reports except first level (first 
level contains error type, number, PC, test and 

unit) 

inhibit extended error reports (those called by 
PR I NT X macro's) 

direct messages to line printer 
print .est number as test executes 
bell’ on error 

unatt *nded mode (no manual intervention) 
inhibit statistical reports (does not apply to 
diagnostics which do not support statistical 
reporting) 

inn bit program dropping of units 
exe ute autodrop code 
locp on test 

execute evaluation (on diagnostics which have 
equation support) 


DRS Command Switches 


/TESTS:test-list 
/PASS: ddddd 
/FLAGS: flag-l'st 
/EOP: ddddd 

/UNlTS:unit-list 
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UPD2 Commands 


F i le Manipulation 


DIR 
PIP 
F HE 
DEL 
REN 

give directory of specified medium 
transfer a file or files 
transfer a file or files 
delete a file or files 
rename a file 

f i le Modi fi cat ion 

CLR 

LOAD 

MOD 

XFR 

HI CORE 
LOCORE 
DUMP 

clear UPD2 program buffer 

load a program 

modify file image in memory 

set transfer address 

set upper memory limit for dump 

set lower memory limit to r dump 

dump a program image 

New Medium Creation 

ZERO 

SAVM 

SAVE 

COPY 

initialize a medium 
save a monitor on a disk 
save a monitor on a tape 
copy entire medium 

Miscellaneous 

ASG 

DO 

READ 

EOT 

DRIVER 

assign a logical name to a device 
execute an indirect command file 
read a file to check validity 
write logical end-of-tape mark on a tape 
load a device driver 

Returning 

to Monitor 

BOOT 

EXIT 

bootstrap a device 

return control to the runtime monitor 

Printing 


PRINT 

TYPE 

print a file on the line printer 
type a file on the console terminal 


PATCH Commands 


BOOT 

CLEAR 

EXIT 

GETM 

GE TP 

KILL 


Boot specified device 

Clear input table 

Return to XXDP+ monitor 

Load DEC/Xl 1 MAP file 

Load saved input table 

Delete address from input table 
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MOD Enter address in input table 

PATCH Crreate patched tile 

SAVP Save input table 

TYPE Print input table on terminal 


XTECQ Non-edit, Commands 


TEXT - create new text file 
TECO - modify a file on disk 
EDI T - modi fy a f i le 

TYPE - type a file on tne console terminal 
PRINT - print a file on the line printer 
EXIT - return to monitor 


XTECO Edit Commands 


Pointer Location 


L - move the pointer line by line 
C - move the pointer character by character 
J - move the pointer to the beginning of text 
ZJ - move the pointer to the end of text 

Search 


S - search for specified string in text now in memory 
N - search for specified string in remainder of text file 

Modify/Display Text 


T - type text 
D - delete character(s) 

K - delete line(s) 

I - insert text 

A - append text to that currently in memory 
Terminating Edit Mode 


EX - exit edit mode 
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User Tips 


ORS Table Building 


To save time and energy, prebuild the hardware and software 

tables in a diagnostic using the SETUP utility. Customize the 

files for a specific system on the XXDP* medium for that system 
or customize files for several systems on median shared between 
systems. Remember, you can always change the tables on the fly 
by using the START command or permanently change the files by 
using SETUP. 

Another way to make XXDP+ work for you is to use the batch 
control functions described in Part VI J of this manual. 

Familiarize yourself with the DRS-type diagnostics for a 
particular device and identify the various operating modes (as 
defined by the software tables) that are most useful for you. 
Prebuild the hardware tables for the system, or systems, you are 
working with. Then write a batch control file that implements 
the various modes based on conditionals. This allows you to 
enter one command to XXDP+ and then let the system do the rest. 

A simple example of this type of batch control file is follows. 
For the purposes of this example, we will use a fictional 
diagnostic called ’T)IAG1”. The normal operator dialogue with 
this diagnostic (with hardware tables already built) is.* 

.R DJAG1 
DR>STA 

CHANGE HW (L) ? N 

CHANGE SW (L) ? V _ 

TEST AU SECTORS (L) ? " 

The batch file that has been created for this diagnostic is 
called "D J SK . CCC" and is listed below. 

IF OV THEN 
R 0IAG1 
STA/PAS : 1 
N 
V 
N 

[NO 

IF REPAIR THEN 
R 0IAG1 

sta/fla.-loe 

N 

y ' . 

y 

N 

END 


■* 


I 


SfO ovs 


I 10 

XXDP* System User’s Manual Page 125 

Appendices 




This file defines two test modes: quick verify and repair. Mote 
how the batch tile manipulates the software Questions and also 
avoids answering the hardware questions since the tables were 
already created. The user invokes either of the two modes with 
one of the following commands: 


C DISK/QV 
or 

C DISK/REPAIR 


! 
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Appendix G 


Glossary 


This is a glossary of common terms used in connection with XXDP*. 

autodelete - a possible effect of the file transfer process 
whereby a file from the input medium replaces a file of the 
same name on the output mediun. In UPD2, only transfers 
initiated by a FILE command can result in autodelet ion. 

boot block - the first physical block an a medium (block zero). 
This block contains the XXDP* secondary bootstrap for the 
device. 

bootstrap - very simple code used to load and start more complex 
code from a medium such as a disk. The term comes from the 
phrase 'Picking oneself up by the bootstraps". See also 
■primary bootstrap" and secondary bootstrap '. 

buffer - a section of memory reserved for storing data, usually 
from, a file, as opposed to executable code 

console terminal - the video or hardcopy terminal attached to the 
system via the DL interface at bus address 177560. 

device driver - that software which has the function of 
controlling the operation of a spec i f i c Hardware component 
in a system. An RX01 driver, for example, is that software 
that accomplishes such tasks as selecting a physical block, 
reading a block of information, etc. on an RxQI disk . 

device handler - see "device driver" 

dump - the process whereby an image of the contents of memory is 
placed on a storage medium. 

edit - to modify text information in a file 

editor - a utility program used to modify text files 

hardware table - data structure where ORS stores the information 
regarding units being tested 

toad - the process whereby the contents of a file containing a 
program image are placed in memory. 

medium - physical storage such as a disk or magtape. In this 
manual, the term 'medium" is equivalent to ^XO 0 * medium", 

pass - a unit of diagnostic operation. A ORS-type diagnostic 
pass is defined to be execution of all specified tests on 
alt active units. 
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patch - a temporary remedy for a problem in a program that is 
accomplished by altering the program image stored on the 
XXDP* medium. See Chapters 11. 12 and 13 for descriptions 
of the various methods of altering the program image. 

physical block - a group of data consisting of 256 (decimal) 
words. This is the standard size of data transmission to 
and from the XXDP* media. 

physical location - an absolute memory reference (see "virtual 
I ocat ion* ') . 

primary bootstrap - code, usually stored in a POM. which loads 
the ‘boot block" (block 0) from » medium into the first 256 
(decimal) words of memory and then transfers control to 
memory locat ion 0. 

program buffer - a section of memory used by UPD2 for loading 
program images. 

secondary bootstrap - code that resides in the boot block (block 
0) of a median. This code is loaded and started by the 
primary bootstrap and in turn loads an starts the XXDP* 
moni tor . 

software table - data structure where OPS stores information 
regarding operational characteristics of a diagnostic 

switch - a modifier for a command 

system medium •* the median on the device from which the rxpp* 
System was booted 

text - a collection of ASCII formatted data consisting of 
printing characters, tabs, carriage returns and form feeds. 

virtual location - a relative memory reference. A program image 
that has been loaded into tre program b» ffer by U**02 uses 
virtual locations; that is, orogram location 0 is not 
physical memory location 0, it is the first physical memory 
location in the program buffer. the XXDP* monitor does 
absolute loads and in this case program location 0 is not 
virtual, but is actually memory location 0. 

XX0P* medium - physical storage, such as a disk pack, MA&taoe, 
cassette, etc . , that has been formatted or xxpp* use. 
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